The Tool Shed: bash history shortcuts
The Story
The old Greybeard down the hall starts complaining that ``you're getting sloppy at the shell, youngster''. You look down at your computer, a fire-breathing 8Ghz quad-CPU beast with RAM that it's probably measured in cubic yards. ``Errrr?'' seems like the most appropriate reply.
``Don't worry, I'll fix ya'' the Greybeard says menacingly.
The next morning you arrive at work only to discover that your FireBreather 3000 has been replaced with ... an old DECStation 5000/25. That 25, by the way, refers to the Mhz of the CPU (a MIPS R3000). It's not all bad, though, since this is a classic Unix workstation. It's like working with living history.
After about 15 minutes of poking around the filesystem, and you're ready to get to work.
After about two minutes of attempting to work, you realize that he Greybeard was right. You'd been getting sloppy with using the shell efficiently, and this little computer makes you pay for it by waiting. And waiting. And waiting.
So you start digging up your old notes and reading through them. It's a matter of necessity now :-)
The Details
Note that these shortcuts were written with the bash shell in mind, but similar shortcuts are available in other advanced shells (such as zsh, ksh and tcsh).
- Use the time command to benchmark how long a command takes to run. This helps you discover if your supr-l33t tricks are actually helping or not.
- Using wildcards efficiently: rather than doing something like 'rm /some/other/dir/*', try it like this '(cd /some/other/dir; rm *)'. If you can figure out why this works you'll have gone a long way to understand how the kernel handles path searching.
- Don't use cat unnecessarily. Instead of 'cat file1 | grep someword > file2', drop that cat and do 'grep someword < file1 > file2'.
- Use printenv to check out how big your environment is. Since it has t be copied every time your start a subprocess, keeping it lean can improve the execution time of loops that launch a lot of processes.
- If you don't really care when a command runs, run it with batch. By default, batch only runs the command when the load average drops below 0.8. This can prevent further loading a computer when it's already busy.
- Try use use the builtin commands of a shell rather than commands that require firing off a new processes. In extreme cases, 'echo *' can be used instead of ls.
- Different implementations of the grep command have very different performance characteristics. Testing out a couple of versions, perhaps with the time command mentioned above, is probably worthwhile for this common command.
- On systems where /bin/sh really is /bin/sh (and not jus a symbolic link to bash, ensure that your shell scripts use it and not bash. It's quite a bit smaller and thus loads and runs quicker.
The Wrap-up
The little DecStation turns out to be a very capable machine as long as you treat it well. You grow fairly fond of it and decide to keep it as your workstation (you can always telnet to the FireBreather if you have a task that needs more horsepower).
That just leaves the little matter of revenge ...
The next morning the Greybeard comes in to work and discover that his FireBreather 3000 has been replaced with ... a 486. Running Windows 3.1.
That'll teach him :-)
