|< Day Day Up >|
In Chapter 6 we talked about using getopts to obtain options and arguments passed in to a shell script. This command makes it easy for the script programmer to process what the user has provided, but what about the other half of the deal? The programmer must make an effort to make life as easy for the user as possible. Nothing makes a user more irate than a script that doesn't take standard arguments, doesn't provide a usage message, doesn't process the arguments in the expected way, and forces the user into a way of thinking that the programmer thinks is the right way. Having to examine the source code for a script to find out what is an acceptable argument or option is usually the last straw!
The Free Software Foundation has published a set of guidelines for writing GNU software that suggests standard ways in which UNIX utilities should operate. When writing your own shell scripts, it is worthwhile to follow the guidelines because your script will then look familiar to users who have used other command-line programs.
At a minimum your script should provide single letter options (such as -h) and long options with the double dash (such as help). It should also provide two options: help and version. From the GNU manual:
For commands that take one or more input files and produce an output file it is considered good practice to make only the input files normal arguments (i.e., command filename ) and have the output file specified by an option (i.e., command -o filename ).
Another thing to watch out for is assuming that a particular environment variable needed by your script has been set in the users' environment. If your script is relying on the user to have set an environment variable, it is probably better to redesign your script to allow the value to be passed in as an argument.
|< Day Day Up >|