4.2. Writing Scripts

4.2.1. The PATH environment variable

To run a command, any command; the shell must be able to locate the file the implements that command. Linux shells do this by searching the PATH environment variable. PATH is an environment variable that is initially set up by the system wide startup scripts. It consists of a set of colon (:) separated directory paths. Unix shells search for commands in the directory paths in the PATH variable in the order in which they occur in the PATH variable.

When the bash shell starts, it will (usually) source the ~/.bashrc script file automatically. For exceptions to this, see the section about building desktop shortcuts in this chapter. You can use this script to change the value of the PATH variable. Note that since the bash does not have any 'built-in' path, you should usually only add elements to PATH rather than replacing it.

In most environments, the directory ~/bin is part of the path. We therefore strongly recommend that scripts either be installed in that directory or, more maintainably, a soft link be made in the ~/bin directory that points to scripts that are part of your system integration work.

Many users want to be able to run scripts and rograms that are located in their current working directory, by just typing their name rather than having to type ./somescript. You can do this by adding a line to your ~/.bashrc file that appends the directory . to the path, for example:

export PATH=$PATH:.
        

4.2.2. Making script files directly executable

Once you have prepared a script file we need to make it directly executable. To do this we must:

• Adjust the file permissions so that the file is executable

• Ensure that when the file is executed, the correct command interpreter is started to interpret the contents of the script.

• Ensure that the shell can locate the script.

Use the chmod unix command to set the permissions of the scripts to permit execution:

chmod a+x myscript ascript.tcl
                

The script itself describes the interpreter to use to process it. If the script begins with the special sequence of characters: #! the remainder of that line are considered to be the path of the command that will interpret the file.

#!/bin/bash
#!/usr/bin/tclsh
                

Note that the full path to the interpreter must be provided, PATH will not be searched. There are two other pitfalls to keep in mind:

• If you prepare your script using a windows system, the lines shown in the example above will end with a carriage return linefeed. Since Linux/Unix expects lines to end with a linefeed only, the script will not run and you will get the error message: : bad interpreter: No such file or directory . The command dos2unix can be used to correct this problem.

  If you intend your tclsh or wish script to run in unix systems outside the NSCL, be aware that the path to tclsh and wish is not necessarily the same in all Linux distributions. There is a trick that can be used to ensure that as long as tclsh or wish are in the PATH it can be found and run.

  This trick depends on the fact that tclsh and wish allow continuation markes in comments, while the sh shell does not. Consider the follwing example.

  Example 4-3. Locating tclsh in the path

  
  !/bin/sh
  #  Start wish now: \
  exec tclsh ${0} ${@}
  
  ... tcl script follows.
                              

  When the script is executed, the sh shell is run. The sh shell does not honor the continuation character \ in its comment so it will run the exec command to run tclsh handing it all the command line parameters. If tclsh is in the path, it will be located and run. When tclsh interprets the script, it will honor the \ as a continuation character and the exec tclsh ${0} ${@} line will be considered part of the preceding comment line.

To ensure that our scripts will be located we could do any of the following:

1. Add the directory containing our scripts to the PATH

2. Install the script in ~/bin

3. Make a symbolic link in ~/bin to the script.

The first choice can lead to long PATH commands which can be unwieldy. The second option either loses the logical directory structure you are trying to maintain in your development, or can cause errors if you forget to install a script that has been modified. Therefore, we will make a symbolic link. Suppose the two scripts are located in the directory ~/sillyscripts:

ln -s ~/sillyscripts/myscript    ~/bin/myscript
ln -s ~/sillyscripts/ascript.tcl ~/bin/ascript.tcl