Starting 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.[1] 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.

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

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:

—version

This option should direct the program to print information about its name, version, origin, and legal status, all on standard output, and then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

—help

This option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.
Near the end of the —help option's output there should be a line that says where to mail bug reports. It should have this format:

 

 
  • Report bugs to mailing-address.
Table 11-1 lists a few of the common single-letter and long options that you may consider using for your own scripts. This list is by no means exhaustive and is intended merely for guidance.

Table 11-1. Possible options

Long option

Option

Examples where used

—all

-a

du, ls, nm, stty, uname, unexpand

—append

-a

etags, tee, time

—binary

-b

cpio, diff

—blocks

-b

head, tail

—date

-d

touch

—directory

-d

cpio

—exclude-from

-X

tar

—file

-f

fgrep

—help

-h

man

—long

-l

ls

—line

-l

wc

—links

-L

cpio, ls

—output

-o

cc, sort

—quiet

-q

who

—recursive

-r

rm

—recursive

-R

ls

—silent

-s

Synonym for -quiet

—unique

-u

sort

—verbose

-v

cpio, tar

—width

-w

pr, sdiff

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.

 

[1] The document is available at http://www.gnu.org/prep/standards/.