11.1 Shell Script Basics
Bourne shell scripts generally start with the following line, which indicates that the /bin/sh program should execute the commands in the script file. (Make sure that there’s no whitespace at the beginning of the script file.)
#!/bin/sh
The #! part is called a shebang; you’ll see it in other scripts in this book. You can list any commands that you want the shell to execute following the #!/bin/sh line. For example:
#!/bin/sh
#
# Print something, then run ls
echo About to run the ls command.
ls
With the exception of the shebang at the top of a script, a # character at the beginning of a line indicates a comment; that is, the shell ignores anything on the line after the #. Use comments to explain parts of your scripts that could be difficult to understand for others reading your code or to jog your own memory when you come back to the code later.
As with any program on Unix systems, you need to set the executable bit for a shell script file, but you must also set the read bit in order for the shell to be able to read the file. The easiest way to do this is as follows:
$ chmod +rx script
This chmod command allows other users to read and execute script. If you don’t want that, use the absolute mode 700 instead (and refer to Section 2.17 for a refresher on permissions).
After creating a shell script and setting read and execute permissions, you can run it by placing the script file in one of the directories in your command path and then running the script name on the command line. You can also run ./script if the script is located in your current working directory, or you can use the full pathname.
Running a script with a shebang is almost (but not quite) the same as running a command with your shell; for example, running a script called myscript causes the kernel to run /bin/sh myscript.
With the basics behind us, let’s look at some of the limitations of shell scripts.
The shebang doesn’t have to be #!/bin/sh; it can be built to run anything on your system that accepts scripting input, such as #!/usr/bin/python to run Python programs. In addition, you might come across scripts with a different pattern that includes /usr/bin/env. For example, you might see something like #!/usr/bin/env python as the first line. This instructs the env utility to run python. The reason for this is fairly simple; env looks for the command to run in the current command path, so you don’t need a standardized location for the executable. The disadvantage is that the first matching executable in the command path might not be what you want.
11.1.1 Limitations of Shell Scripts
The Bourne shell manipulates commands and files with relative ease. In Section 2.14, you saw the way the shell can redirect output, one of the p. 293 important elements of shell script programming. However, the shell script is only one tool for Unix programming, and although scripts have considerable power, they also have limitations.
One of the main strengths of shell scripts is that they can simplify and automate tasks that you can otherwise perform at the shell prompt, like manipulating batches of files. But if you’re trying to pick apart strings, perform repeated arithmetic computations, or access complex databases, or if you want functions and complex control structures, you’re better off using a scripting language like Python, Perl, or awk, or perhaps even a compiled language like C. (This is important, so you’ll see it throughout the chapter.)
Finally, be aware of your shell script sizes. Keep your shell scripts short. Bourne shell scripts aren’t meant to be big, though you will undoubtedly encounter some monstrosities.