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
rm * 2>/dev/null rmdir <directory> 2> /dev/null cp -p * <directory> 2> /dev/nullYou 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 fiYou 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/nullYou 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/statlogThis exec trick doesn't only work with standard error, of course. You can send standard out to a file with a similar command:
exec > logfileYou can also read data from a file using exec:
exec < datafile read firstline read secondlineThe 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 helloSimilarly, 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 bashWhile 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.