Executing Commands with bash
(Page 1 of 5 )
This two-part article will explain how to launch programs in the bash shell, used with Linux and Unix operating systems. It is excerpted from chapter four of the
bash Cookbook, Solutions and Examples for bash Users, written by Carl Albing, JP Vossen and Cameron Newham (O'Reilly, 2007; ISBN: 0596526784). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
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.
Solution Use bash and type the name of the command at the prompt.
$ someprog
Discussion 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 andif/then/elsebranching, 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$PATHto locate your executable. The$PATHvariable 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 $PATH
/bin:/usr/bin:/usr/local/bin:.
$
In the$PATHvariable 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$PATHis 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 unwittingly run that command. Don’t believe us? Try this:
$ bash
$ 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$PATHvariable, 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
customized 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.
See Also
Next: 4.2 Telling If a Command Succeeded or Not >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of the bash Cookbook, Solutions and Examples for bash Users, written by Carl Albing, JP Vossen and Cameron Newham (O'Reilly, 2007; ISBN: 0596526784). Check it out today at your favorite bookstore. Buy this book now.
|
|
