Classic Shell Scripting - Arnold Robbins [16]
HP-UX 10, 11
127
IBM RS/6000
AIX 4.2
255
Intel x86
FreeBSD 4.4
64
Intel x86
FreeBSD 4.9, 5.0, 5.1
128
Intel x86
NetBSD 1.6
63
Intel x86
OpenBSD 3.2
63
SGI MIPS
IRIX 6.5
255
Sun SPARC, x86
Solaris 7, 8, 9, 10
1023
[4] All architectures.
The POSIX standard leaves the behavior of #! "unspecified." This is the standardese way of saying that such a feature may be used as an extension while staying POSIX-compliant.
All further scripts in this book start with a #! line. Here's the revised nusers program:
$ cat nusers
Show contents
#! /bin/sh - Magic #! line
who | wc -l Commands to run
The bare option - says that there are no more shell options; this is a security feature to prevent certain kinds of spoofing attacks.
* * *
[3] /bin/csh is the C shell command interpreter, originally developed at the University of California at Berkeley. We don't cover C shell programming in this book for many reasons, the most notable of which are that it's universally regarded as being a poorer shell for scripting, and because it's not standardized by POSIX.
Basic Shell Constructs
In this section we introduce the basic building blocks used in just about all shell scripts. You will undoubtedly be familiar with some or all of them from your interactive use of the shell.
Commands and Arguments
The shell's most basic job is simply to execute commands. This is most obvious when the shell is being used interactively: you type commands one at a time, and the shell executes them, like so:
$ cd work ; ls -l whizprog.c
-rw-r--r-- 1 tolstoy devel 30252 Jul 9 22:52 whizprog.c
$ make
...
These examples show the basics of the Unix command line. First, the format is simple, with whitespace (space and/or tab characters) separating the different components involved in the command.
Second, the command name, rather logically, is the first item on the line. Most typically, options follow, and then any additional arguments to the command follow the options. No gratuitous syntax is involved, such as:
COMMAND=CD,ARG=WORK
COMMAND=LISTFILES,MODE=LONG,ARG=WHIZPROG.C
Such command languages were typical of the larger systems available when Unix was designed. The free-form syntax of the Unix shell was a real innovation in its time, contributing notably to the readability of shell scripts.
Third, options start with a dash (or minus sign) and consist of a single letter. Options are optional, and may require an argument (such as cc -o whizprog whizprog.c). Options that don't require an argument can be grouped together: e.g., ls -lt whizprog.c rather than ls -l -t whizprog.c (which works, but requires more typing).
Long options are increasingly common, particularly in the GNU variants of the standard utilities, as well as in programs written for the X Window System (X11). For example:
$ cd whizprog-1.1
$ patch --verbose --backup -p1 < /tmp/whizprog-1.1-1.2-patch
Depending upon the program, long options start with either one dash, or with two (as just shown). (The < /tmp/whizprog-1.1-1.2-patch is an I/O redirection. It causes patch to read from the file /tmp/whizprog-1.1-1.2-patch instead of from the keyboard. I/O redirection is one of the fundamental topics covered later in the chapter.)
Originally introduced in System V, but formalized in POSIX, is the convention that two dashes (--) should be used to signify the end of options. Any other arguments on the command line that look like options are instead to be treated the same as any other arguments (for example, treated as filenames).
Finally, semicolons separate multiple commands on the same line. The shell executes them sequentially. If you use an ampersand (&) instead of a semicolon, the shell runs the preceding command in the background, which simply means that it doesn't wait for the command to finish before continuing to the next command.
The shell recognizes three fundamental kinds of commands: built-in commands, shell functions, and external commands:
Built-in