Executable scripts
Suppose you have written a script, called (say)
myprogram. In order to execute the commands in this
file, we have indicated that they must be passed to the shell. Now,
using
$ sh myfile
a copy of the shell command interpreter is created for the sole
purpose of executing the commands in myfile and, when
it has finished with them, the new shell terminates. Typing
sh each time can be tedious, especially if you have
written many scripts; if you change the permissions on
myfile so that you have execute permission
for it, then it can be run as any other command:
$ chmod +x myfile
This is the same as
$ chmod a+x myfile
which gives execute permission to all users. You can now type
just the name of the file and it will run:
$ /home/ugrad/chris/myfile
For example, if you create a file called mydate and
containing
echo The date and time is:
date
then you could run the script by
$ $HOME/mydate
Alternatively, give it the name relative to the current
directory:
$ ./mydate
Finally, examine the value of your PATH:
$ echo $PATH
If there is a dot as one of the components of PATH
the current directory will also be searched, and you can then
simply type mydate
$ mydate
Worked example
Update your PATH so that it includes the
subdirectory bin of your home directory.
Solution: We assume that you have created the
subdirectory by moving to your home directory using cd
and then typing mkdir bin. The value of
$HOME is the name of your home directory, so the
subdirectory bin can be referred to by
$HOME/bin. The variable PATH contains the
directories, separated by colons, that are searched for. You want
to replace the value of PATH by a new value, which is
the old value with a colon, and then $HOME/bin added
on at the end. You will then need to export the value
of PATH so that child processes will use the new
one.
$ PATH=$PATH:$HOME/bin
$ export PATH
Note that we have added $HOME/bin to the
end of $PATH; it would be unwise to place it
at the start, in case you accidentally include a command in
$HOME/bin that has a name identical to another command
on the system. If this happened, your command would be executed in
preference to the other one, which might have unexpected
consequences. Of course, you might wish to write your own version
of a system command, in which case having $HOME/bin at
the start of $PATH would be necessary, but
you are strongly advised against rewriting system commands.
There is a command . (not to be confused with
directory .) which, when followed by a file that is a
shell script, will cause the commands in the script to be executed
by the calling shell. A new shell is not created. For most purposes
it does not matter whether or not you use sh or
., but if you use sh you should bear in
mind that any environment variables defined in the calling shell
must be exported to be recognised within the script. If you use
. changes you make to the environment will alter the
environment of the current shell.
Worked example
Write a command changeprompt to request you to
enter a new shell prompt and then reset it to its new value.
Solution: The variable PS1 has its
value as your prompt. Create a file to reset its value. Execute the
file using . (not sh) to run the commands
in your interactive shell.
echo Type in the new prompt:
read PS1
export PS1
|