exec -- how the shell executes a command


The UNIX system contains several shells; these are interactive command interpreters. This manual page describes how the Bourne, C, and Korn shells (see sh(C), csh(C), and ksh(C)) execute commands that you have entered.

When you enter a command, the shell tries to match it against several possible entities in order to run it:

  1. user-defined aliases (in csh and ksh)

  2. built-in commands; for example cd, and echo

  3. user-defined functions in the shell (in sh and ksh)

  4. executable files in each of the directories defined in the shell's search path
If you specify an explicit pathname for a command, the shell will attempt to execute that file instead of following steps 1 to 4.

There are two types of executable file that may be run:

You can run an executable file if it is a regular file or a symbolic link to a regular file (it cannot be a directory, a device special file, or a named pipe), and one of the following conditions is met: The Bourne and C shells use the fork(S) system call to generate a new child process that is a copy of the current shell. The child process exists so that your command can take it over; the child invokes the exec system call to run the command in place of the child shell without creating a new process. (exec is also a shell built-in command; it calls exec without doing a fork; the original shell process is replaced by the command given as an argument to exec.) If exec cannot execute the file, the child shell assumes the file is a shell script and runs it itself.

The Korn shell tries to avoid forking if it can. It must fork if the file being executed is not a Korn shell script or if it forms the second or subsequent element of a command pipeline; in these two cases execution proceeds as for the Bourne and C shells. Whenever possible, the Korn shell interprets and runs the commands in the file without calling fork. The shell protects the main execution environment from the effects of commands in the script; this emulates the behavior of a forked process without the consequent overhead.

Execution of a file by exec(S)

exec looks at the start of the file and tries to determine its type; exec can run COFF and OMF format binary executables, and #! scripts. Some systems also allow DOS batch and binary executable files to be run.

Binary executables

Binary executables files have been compiled from program source code and linked into a loadable module. The executable contains a code (the file's magic number) in its header record that encodes the type of executable file. (See magic(F) for more information.) Depending on this type, it may be loaded and run directly on the processor, or read by an emulator that is capable of converting the machine instructions into a form that the processor can understand. The following executable module types can be run:

Module type Emulator or direct
i386 ELF binary direct
i386 COFF binary direct
i386 OMF (x.out) binary direct
i286 COFF binary emulator (/bin/i286emul)
x8086/x80286 OMF (x.out) binary emulator (/bin/x286emul)
DOS executable or batch file emulator (if available)

 |Module type                     | Emulator or direct      |
 |i386 ELF binary                 | direct                  |
 |i386 COFF binary                | direct                  |
 |i386 OMF (x.out) binary         | direct                  |
 |i286 COFF binary                | emulator                |
 |                                | (/bin/i286emul)         |
 |x8086/x80286 OMF (x.out) binary | emulator                |
 |                                | (/bin/x286emul)         |
 |DOS executable or batch file    | emulator (if available) |
If a DOS emulator is available on your system, exec uses it to run DOS executable and batch files. See dos(MERGE) for more information.

Shell scripts

A shell script is a program written in the command language of one of the shell programs. The shells deal with scripts in different ways:

#! scripts

If the first line of an executable file is of the form:

#!interpreter [ argument ]

exec appends all command line arguments (including $0) to the command interpreter and a single optional argument, and loads the resulting command to replace the child shell (see ``Examples''). interpreter must always be fully specified including its path; the form of exec that is used does not search the directories defined by the PATH environment variable.

If the second and subsequent lines of the script are to be interpreted by interpreter, the script must be readable by the invoking user, or interpreter must change the effective user or group ID to one that can read it.

#! scripts are also sometimes referred to as ``hash-bang'', ``hash-pling'', or even ``hash-shriek'' scripts.


A one-line #! script (named bing) that displays all command line arguments (including $0) prefixed by the string ``args:'':
   #!/bin/echo args:
Entering bing one two three four displays:

args: pathname/bing one two three four

pathname is displayed as an absolute or relative path to the bing script.

A #! script that must always be executed by /bin/sh:

A common use of #! is to introduce an executable awk(C) script:
   #!/usr/bin/awk -f
   BEGIN { FS = ":" }
Similarly, #! can be used to introduce a sed(C) script:
   #!/bin/sed -f


The interpretation of #! is a feature of exec and cannot be disabled.

Only one argument can be passed to the interpreter named after the #! entry. Some interpreters require the use of an option to tell them that the next argument is the script filename. For example, you must specify the -f option with both awk and sed.

The interpreter must understand the use of ``#'' to begin comment lines.

Earlier versions of the operating system either did not include the #! feature, or allowed it to be disabled.

A DOS emulator must be available on your system in order to run DOS executables and batch files.


a list of magic number definitions used by file(C)

emulator for i286 COFF (Common Object File Format) binaries

emulator for x8086/x80286 OMF (Object Module Format, or x.out) binaries

See also

csh(C), dos(MERGE), exec(S), file(C), fork(S), ksh(C), magic(F), setuid(S), sh(C)
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003