Launching External Programs

One of the most basic uses of shell scripts is to launch external programs. You do this by placing the name of the external program, possibly preceded by its complete path, in the script, just as you would type the command at a shell prompt. If you include an ampersand (&), the command launches in the background and processing continues to the next command; otherwise, the first command must finish before the next command executes. As an example, consider Listing 4.1, which launches a few X programs—specifically, two xterm instances, xeyes, and icewm. The first three programs are launched in the background, but the final program isn't. Consequently, the script won't finish executing until the final program terminates. This specific example could be used as a simple X startup script, such as an —/.xinitrc file, because icewm is an X window manager. Therefore, the effect is that the X session lasts until the user quits from the window manager—an action that's normally performed to log out or shut down X.

Listing 4.1: A Simple Script to Launch Several X Programs

#!/bin/bash xterm & xterm & xeyes & icewm

You can also combine programs in a pipe or use redirection. Consider Listing 4.2, which shows a script that passes the output of dmesg through the less pager. This script is trivial, but it demonstrates a very powerful principle: By combining individual commands via pipes, you can create a script that performs more complex tasks. If you find yourself regularly typing a long compound command, you may want to place that command in a script and give it a shorter name. You can even use parameters passed to the script as variables to handle variable data required by the commands.

Listing 4.2: A Demonstration of Pipes in a Script

Note When calling a program from a script, you can use a command alone (such as dmesg), use the complete path to a command (such asfoin/dmesg), or create a variable that includes the complete path and use it (as in DMESG=/bin/dmesg, and then use $DMESG to call the command). The first option is most readable and may ease porting the script to another distribution or non-Linux OS. The second option may be more secure because a miscreant can't manipulate the path to have victims run the wrong program. Using the complete path to a program also ensures that the script will work even if the PATH environment variable in the ultimate running environment omits the directory in which a program resides. The third option is a good compromise, and is frequently used on large scripts, but complicates the development of very simple scripts. For readability, I omit the path from most sample scripts in this chapter, but you may want to include them in your own scripts.

Many Linux commands are most useful when they are launched from scripts. Table 4.5 summarizes these commands. Some of them are very complex, so you should consult their man pages for more details. Of course, you can also use commands you might normally type at a shell prompt, such as cd, cp, dd, and so on.

Table 4.5: Commands Frequently Found in Shell Scripts




Simple programming language that produces results based on pattern matches. Linux ships with GNU awk, or gawk; it responds to either name.




Removes portions of an input line.


Sends a constant or variable tostdout.


Does nothing and returns a failure code.


Searches for files matching specified criteria, such as filename or creation date. Sends matching filenames to stdout.


Searches for files containing a specified string. Normally sends the matching lines to stdout.


Returns the process ID (PID) matching a specified running program.


Requests input from the user or from a file.


The stream editor; edits files based on commands passed to sed on the command line or in a script.


Sorts lines ofstdin or from a file and sends the sorted version tcstdout.


Removes duplicate lines from a sorted file or fromstdin.


Does nothing and returns a success code.

0 0

Post a comment