Shell scripts often start with a single line that indicates which shell (or inter-preter) is to be used to execute the script, and where that shell is located.This line begins with a pound sign (#) followed by an exclamation point (!).
Theses symbols are often referred to as a “shabang.” For example, the first line of an OS X bash script should read:
#!/bin/bash
While this first line is optional, it is recommended that you include it, since different shells have slightly different syntax. Executing a bash script from a tcsh prompt will feed bash commands and syntaxes into tcsh, producing unexpected results.
Although shell scripting is extremely powerful, it is also odd in many respects. Here is a breakdown of some of the things to keep in mind:
■ Capitalization matters.Most shells are case sensitive, because UNIX is case sensitive. Variable names and command names must use proper capitalization. From a UNIX perspective, “Bash,” “bash,” and
“BASH” describe three different things.
acter” that separates commands from arguments. When sending a command to a shell, for example the ls -lacommand, the first “word”
is the name of the command (ls) and the following “words” are argu-ments to the ls command (-la). Do not recklessly add or delete spaces from the example scripts in this section.
■ Shells rely on external commands. One thing that makes shell scripting so powerful is that it ties together the best features of many external programs. As a shell programmer, you need to be keenly aware of the syntax of the external commands you are asking the shell to execute. Knowing shell syntax is useless if you are fumbling your way through the grep,sed and awkcommands that you are relying on.
■ Pipes can break.The output from one program can easily be fed into another program, and that output can be fed into another pro-gram, and so on- ad infinitum. While this is a powerful feature, it tends to cause beginners a bit of a headache until they get the hang of it.This piping of information can be a bit of a hassle, especially if your really long “pipes” start leaking bad data somewhere in the middle.Garbage in, Garbage out.
■ As mentioned, shell scripts can be entered into a file or run from the command line.If you start typing in a multi-line shell script at the shell prompt, bash will “understand” that you are not fin-ished entering the script, and wait until the script is completely typed in before executing it. If a shell command entered at a prompt throws you a strange-looking prompt character (e.g., a greater-than sign), type Control-C to get things back to normal.
Pipes
Most programs produce some sort of output. UNIX shells are known for their awesome ability to “chain” this output and input together with the pipe character (“|”). For example, consider this simple command:
j0pb12:~ johnnylong$ echo shmoo shmoo
In this example, we provide the word “shmoo” to the echo command as input, and the command produces the word “shmoo” as output. Consider another command:
The tr command translates characters. In this example, we are asking tr to translate every ‘o’ character into an ‘e.’ After entering the command, the shell waits for input. If we type food, the tr program translates the characters and produces the word feed. Likewise, typing mow produces the word mew.The tr command accepts input, manipulates that input, and produces output.
Combining the two examples, we can use the pipe to send the output of the echocommand into the tr program as input:
j0pb12:~ johnnylong$ echo shmoo | tr 'o' 'e' shmee
When the word “shmoo” is piped through the tr ‘o’ ‘e’command, the output is the word “shmee.”These pipes can be used to connect any program that accepts piped input; most UNIX commands do. Some commands require a special switch to read piped data (sometimes referred to as reading from stan-dard inputor reading from stdin), but most UNIX commands accessible from the Terminal are already set up to accept input from another command’s piped output without any switches.
Redirection
There are other ways to manipulate input and output, specifically the use of redirection.Similar to using the pipe, redirection is most often used to send output to or read output from a file. Redirection is accomplished through the use of the greater-than (>) and less-than (<) symbols. Consider this variation of our simple echo command:
j0pb12:~ johnnylong$ echo shmoo > foo.txt j0pb12:~ johnnylong$ cat foo.txt
foo.txt command shows that the output was, in fact, written to foo.txt.The greater-than symbol is used to send output to a file. A single >symbol will cause the target file to be overwritten.To append to an existing file (or begin writing to an empty file), use two >symbols:
j0pb12:~ johnnylong$ echo shmoo >> foo.txt j0pb12:~ johnnylong$ cat foo.txt
shmoo shmoo
Notice that there are no spaces between the >symbols. A space between redirect symbols will produce an error, because output can only be redirected once per command.
j0pb12:~ johnnylong$ echo oops > > foo.txt -bash: syntax error near unexpected token `>'
The < symbol is used to read from a file. We won’t spend much time dis-cussing the use of the less-than symbol, as it is more common to use a pro-gram like catto pipe the contents of a file into another program.These two commands are (practically) identical as written, but the second tends to looka bit awkward to a novice shell user:
j0pb12:~ johnnylong$ cat foo.txt | more shmoo
shmoo
j0pb12:~ johnnylong$ more < foo.txt shmoo
shmoo
Either way, both of these commands send the output to the more com-mand, which presents output one page at a time, and allows you to scroll back and forth through the file. Redirections can be chained ad-nauseum, and we’ll get some wicked chaining going in relatively short order.