The main purpose of bash (or of any shell) is to allow you to interact with the computer’s operating system so that you can accomplish whatever you need to do. Usually that involves launching programs, so the shell takes the commands you type, determines from that input what programs need to be run, and launches them for you.

Let’s take a look at the basic mechanism for launching jobs and explore some of the features bash offers for launching programs in the foreground or the background, sequentially or in parallel, indicating whether programs succeeded and more.

4.1  Running Any Executable

Problem

You need to run a command on a Linux or Unix system.

Use bash and type the name of the command at the prompt.

  $ somepro g

This seems rather simple, and in a way it is, but a lot goes on behind the scenes that you never see. What’s important to understand about bash is that its basic operation is to load and execute programs. All the rest is just window dressing to get ready to run programs. Sure there are shell variables and control statements for looping and if / then / else branching, and there are ways to control input and output, but they are all icing on the cake of program execution.

So where does it get the program to run?

bash will use a shell variable called $PATH to locate your executable. The $PATH vari able is a list of directories. The directories are separated by colons ( : ). bash will search in each of those directories for a file with the name that you specified. The order of the directories is important—bash looks at the order in which the directories are listed in the variable, and takes the first executable found.

  $ echo $PAT H
  /bin:/usr/bin:/usr/local/bin:.
  $

In the $PATH variable shown above, four directories are included. The last directory in that list is just a single dot (called the dot directory, or just dot), which represents the current directory. The dot is the name of the directory found within every directory on a Linux or Unix file system—wherever you are, that’s the directory to which dot refers. For example, when you copy a file from someplace to dot (i.e., cp  /other/place/file  . ), you are copying the file into the current directory. By having the dot directory listed in our path, bash will look for commands not just in those other directories, but also in the current directory (.).

Many people feel that putting dot on your $PATH is too great a security risk—someone could trick you and get you to run their own (malicious) version of a command in place of one that you were expecting. Now if dot were listed first, then someone else’s version of ls would supersede the normal ls command and you might unwit tingly run that command. Don’t believe us? Try this:

  $ bas h
  $ cd
  $ touch ls
  $ chmod 755 ls
  $ PATH=".:$PATH"
  $ ls
  $

Suddenly, the ls appears not to work in your home directory. You get no output. When you cd to some other location (e.g., cd  /tmp ), then ls will work, but not in your home directory. Why? Because in that directory there is an empty file called ls that is run (and does nothing—it’s empty) instead of the normal ls command located at /bin/ls. Since we started this example by running a new copy of bash, you can exit from this mess by exiting this subshell; but you might want to remove the bogus ls command first:

  $ cd
  $ rm ls
  $ exit
  $

Can you see the mischief potential of wandering into a strange directory with your path set to search the dot directory before anywhere else?

If you put dot as the last directory in your $PATH variable, at least you won’t be tricked that easily. Of course, if you leave it off altogether it is arguably even safer and you can still run commands in your local directory by typing a leading dot and slash character, as in:

  $ ./myscript

The choice is yours.

Never allow a dot or writable directories in root’s $PATH . For more, see Recipe 14.9, “Finding World-Writable Directories in Your $PATH” and Recipe 14.10, “Adding the Current Directory to the $PATH.”

Don’t forget to set the file’s permissions to execute permission before you invoke your script:

  $ chmod a+x ./myscript
  $ ./myscript

You only need to set the permissions once. Thereafter you can invoke the script as a command.

A common practice among some bash experts is to create a personal bin directory, analogous to the system directories /bin  and /usr/bin where executables are kept. In your personal bin you can put copies of your favorite shell scripts and other
custom ized or private commands. Then add your home directory to your $PATH , even to the front ( PATH=~/bin:$PATH ). That way, you can still have your own customized favorites without the security risk of running commands from strangers.

1. Chapter 16 for more on customizing your environment
   
2. Recipe 1.3, “Finding and Running Commands”
   
3. Recipe 14.9, “Finding World-Writable Directories in Your $PATH”
   
4. Recipe 14.10, “Adding the Current Directory to the $PATH”
   
5. Recipe 16.9, “Keeping a Private Stash of Utilities by Adding ~/bin”
   
6. Recipe 19.1, “Forgetting to Set Execute Permissions”