The Whole Shebang, or What's in a Script

When using a text login environment, or a text-oriented terminal connection to some other Linux or Unix computer, the typical interaction is for the shell process (such as bash) to show a prompt, then for the user to enter a command, and finally for the shell to show any output resulting from that command. The process then repeats: prompt, command, output, prompt, command, output. Also, if in the execution of those various commands, one should happen to require the user's further input, the shell should pass whatever the user types into those programs without delay.

In the sample output below, the blue dollar signs ($) are the prompts, the green text is the user's commands, and the white text is the output from each command, as reported by the shell environment. These commands themselves aren't very useful; they're just handy as an example.

$ date Sun Feb 30 17:39:05 CST 2002 $ for each in 1 2 ; do echo $each ; done 1 2 $ ls -asFC total 72 4 ./ 60 portrait.xpm.gz 4 ../ 4 sample.sh* $

A shell script is merely a list of commands to be executed in the proper order by a shell environment like bash. A shell script can do anything that you could type manually. Conversely, you could type anything that a shell script contained, to do the same tasks manually. Consider a text file called sample.sh that included just the commands entered above, as the following lines of text:

date for each in 1 2 ; do echo $each ; done ls -asFC

To execute such a script file, all you need to do is to tell your own shell to use its contents as a source of commands. Your current shell process will then rush through all of the included commands, executing them one at a time on your behalf, until it has run all of them. It then returns control back to you.

$ source sample.sh Sun Feb 30 17:42:25 CST 2002 1 2 total 72 4 ./ 60 portrait.xpm.gz 4 ../ 4 sample.sh* $

However, some shell scripts are written using the commands for some other type of shell. These scripts would throw out error messages, or worse, if they were attempted in the user's current shell environment instead of the environment that was chosen by the script's author.

To combat these problems, and to make shell scripts more flexible in general, there are two steps to converting a shell script into a full-fledged command that can then be invoked by any program as its very own process.

First, the file needs to specify which type of shell environment should be created to execute the shell script's commands. This is done as a special notation on the first line of the shell script. The line begins with a number sign (#), then an exclamation point (!), followed by the exact executable shell program on this computer's filesystem. Below, this new line is inserted into our sample script file.

#!/bin/bash date for each in 1 2 ; do echo $each ; done ls -asFC

Some old-time Unix developers call this (#) a hash, and call this (!) a bang, ostensibly to read their programs aloud easier when discussing them. The combination of (#!) together is sometimes called hash-bang, but many now use the slang term shebang for this notation.

Second, the file needs to be marked as having executable permissions. The script will need to create a new shell environment of the type given above, which is a whole new process added to the kernel, so it must have its own information about access permissions. To make the file sample.sh executable by its user only, perform the following command:

$ chmod u+x sample.sh $

Lastly, you can now test the file. When a user tries to execute any file, the kernel will check the first two characters for a shebang, and if found, it will start a whole new process with the given shell environment. That shell process will then execute the commands as they are listed, just as we tried before. In the transcript below, you'll see that the system can't find the newly made command with the default path, so on the second try, the current directory (.) is specified to help the shell find the script.

$ sample.sh bash: sample.sh: command not found $ ./sample.sh Sun Feb 30 18:02:31 CST 2002 1 2 total 72 4 ./ 60 portrait.xpm.gz 4 ../ 4 sample.sh* $

Two final notes:

There are many shell script interpreters, and some that are not even intended for use as an interactive command prompting space for users to type their commands. For example, Perl scripts may start with a shebang line similar to #!/usr/local/bin/perl. They're still interpreted by that process and any code within is executed on behalf of the user who invoked the command.

Also, note that the filename has nothing to do with the type of shell required for running the script. The script could have been called sample, or sample.pl or even kernel.exe. In Unix and Linux, it is the contents (such as its shebang), and not the name, which determines how the system will go about executing or opening the file. Many of the commands you run in Linux are just shell scripts that have no filename extensions.

Some helpful manual pages on your Linux system may be (help source), (man bash), (man chmod), and (man perl).

Some helpful google searches may be linux shell commands scripts, linux shebang notation, linux bash PATH variable, linux file mode permissions, and common scripting languages.

Contact Ed Halley by email at ed@halley.cc. Text, code, layout and artwork are Copyright © 1996-2005 Ed Halley. Copying in whole or in part, with author attribution, is expressly allowed. Any references to trademarks are illustrative and are controlled by their respective owners.