Everybody’s linking to Ryan Tomayko’s post, I like Unicorn because it’s Unix, but I’m not going to let it keep me from linking to it as well. It’s a paean to the Unix design philosophy, and really illustrates how few applications these days are built on that philosophy. Go read it. It’s good.
Here’s a Unix shell lesson I always forget. Shell commands can send output to two places, standard output and standard error. The two are separated so that if you’re redirecting the output of the command to a file or piping it to another command, error messages generated by the command aren’t included with the expected output of the command.
This becomes a problem when you want to capture STDERR in a file, or pipe it to a command like grep so that you can search for specific things in the errors.
Fortunately, there’s a way to do this:
$ my_command 2>&1 | grep "somestring"
The magic here is 2>&1. It means, “Redirect stream 2 to stream 1.” In Bourne shell derivatives (like bash, zsh, and ksh), stream 2 is STDERR and stream 1 is STDOUT. Once the streams are merged, you can do whatever you want with the single output stream, like pipe it to grep or redirect it to a file.
One common construct you’ll see in cron jobs is this:
1 0 * * * run_some_script.sh > /dev/null 2>&1
Cron helpfully sends an email to the user that owns the cron job whenever the command cron is running produces any output. Putting the merged redirect to /dev/null in there sends both STDERR and STDOUT to the bit bucket so that no email is generated. Of course that also means that cron is eating the error messages, so if something goes wrong you won’t be notified in the traditional way.
As I discussed a few days ago, I’m always open to a better offer when it comes to tools. Yesterday, Dan Croak write a massive post describing how to set up OS X for Ruby on Rails development. In the post he points to dot files shared on GitHub by Joe Ferris, and mentions that the shell they use is zsh (an alternative to bash that’s based on ksh).
I started wondering about the allure of zsh — I’ve used bash for a long time, and when I started using it, it was the most powerful shell around. I figured that if people were leaving bash for zsh, there must be some compelling reason, and I decided to do some research.
If you’re looking for the zsh argument, Fried CPU outlines the advantages. Item number 4 on his list, “Share history across sessions” was enough to convince me to give it a shot.
After changing my shell with chsh, it was time to start tweaking the shell configuration. I went back and looked at the .zshrc mentioned in Joe Ferris’ post and then I started looking around elsewhere for more. There are a bunch of zsh configuration files at <a href=http://dotfiles.org/.zshrc”>dotfiles.org, and from among them I found _why’s particularly useful. (He has some code that updates the title bar in your Terminal window in a useful fashion that’s a must have.)
We tell ourselves that we live in a rational, scientific society, but Unix configuration files clearly indicate that’s not the case. Various snippets are passed around like bits of ancient lore, with most people who use them having no idea why they do what they do. Count me among the ignorant and possibly superstitious. (See also: sync; sync; halt.) You can find my current zshrc here, but don’t ask me how it works, yet.
The coolest trick I’ve seen zsh pull so far involves svn add. zsh is smart enough to include only files that have not yet been added in the tab completion list when you hit tab after svn add. So if you have a directory of 10 files and only one of them is new, zsh is smart enough to choose that file when you hit tab. I love little bits of brilliance like that.
The secret is that zsh provides a highly extensible system for customizing tab completion, so there are tab completion packages for many tools that handle the special cases. (zsh’s autocompletion library for the kill command is somewhat famous.)
Playing with zsh is the best geeky distraction I’ve found in some time. I’d urge you to check it out.
Tim Bray warns of the dangers of Ruby Gems as an attack vector. The risk is that basically anyone can create a Gem and make it available using the gem installer.
I’ll say that this is why real systems administrators detest the various packaging schemes that scripting languages offer. It’s generally a much better practice to manage libraries through the operating system’s centralized packaging system — Red Hat’s RPM, FreeBSD Ports, Debian/Ubuntu’s APT, and so forth. Administrators who want to go beyond the vendor-approved repositories for packages are free to do so, but packages from the vendor list can be installed with relative confidence.
Who knows what to expect from packages from CPAN, PEAR, RubyForge, and the like? (This also ties into my longer argument about why developers are the natural enemy of the systems administrator, but I’ll get into that some other time.)
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Can you judge someone by their shell prompt?
Tom Ryder on shell prompts:
Should we be asking job candidates for their dot files?