June 03, 2009, 7:27 PM — It is not at all uncommon for script developers to include sporadic lines ending with "2> /dev/null" in their scripts. These redirects send errors to the bit bucket in order to keep them out of sight for anyone running the script, lest they start to believe they've done something terribly wrong.
When a user needs to be alerted to some problem related to running a script, a more gently crafted message can be displayed in place of the rather coarse and unimaginative output of our Unix binaries. The likes of "/tmp/file109: No such file or directory" and similar errors that only the person who wrote the script is likely to understand can be squelched in favor of "Sorry, but you must supply a valid file name" or "Usage: anaperf ".
To squelch the system's messages and replace them with your own, you can add the redirection to the end of the lines that are likely to generate intimidating messages:
rm * 2>/dev/null rmdir 2> /dev/null cp -p * 2> /dev/null
You can then test the return code to see whether an error was generated and supply your own.
if [ $? != 0 ]; then
echo "Sorry, chum, you don't own that file"
exit 1
fi
You can also opt to remove all the line-specific "2>/dev/null" add-ons and, instead include a single line near the top of your scipt to send all error output on its way to bit bliss. Just add a line like that shown below and, from that point forward, all standard error disappears.
# don't display any errors exec 2>/dev/null
You can still generate your own superbly crafted error messages, thus soothing your users' nerves and making them feel good about themselves even if they can't remember that to process a file, they need to supply a file name.
If, instead of tossing away all the errors that are generated, you would like to retain them for whatever reason, you can capture the errors in a file in place of dumping them down the bit bucket with only a slight variation of the command.
# save errors for usage stats exec 2>/opt/statlog
This exec trick doesn't only work with standard error, of course. You can send standard out to a file with a similar command:
exec > logfile
You can also read data from a file using exec:
exec < datafile read firstline read secondline
The exec command can come in handy in a number of interesting ways. The argument you supply to exec is, basically, another command. exec runs the second command without creating a new process. You can think of this as overlaying one process with another. If you were to run the little script shown below, for example, you'd never see the word "hello" being echoed to your screen because the date process would replace the script process.
#!/bin/bash exec date echo hello
Similarly, typing a command as innocuous as "exec ls" will close your shell. Why? Because it overlays the shell process with itself.
To replace one shell with another, you might try "exec shell" as in this example:
# ps PID TTY TIME CMD 27379 pts/3 0:00 ps 27181 pts/3 0:00 sh # exec bash bash-3.00# ps PID TTY TIME CMD 27380 pts/3 0:00 ps 27181 pts/3 0:00 bash
While there are many ways to keep system messages from scaring your users, redirects using exec are neat, tidy and about as easy as they come.
