Otherwise, the shell shall execute a non-built-in utility as described in [xref to 2.9.1.2].

If the command name contains at least one <slash>, the shell shall execute a non-built-in utility as described in [xref to 2.9.1.2].

2.9.1.2 Non-built-in Utility Execution

When the shell executes a non-built-in utility, if the execution is not being made via the exec special built-in utility, the shell shall execute the utility in a separate utility environment (see [xref to 2.12]).

If the execution is being made via the exec special built-in utility, the shell shall not create a separate utility environment for this execution; the new process image shall replace the current shell execution environment. If the current shell environment is a subshell environment, the new process image shall replace the subshell environment and the shell shall continue in the environment from which that subshell environment was invoked.

In either case, execution of the utility in the specified environment shall be performed as follows:

1.

If the command name does not contain any <slash> characters, the command name shall be searched for using the PATH environment variable as described in [xref to XBD Chapter 8]:

a.

If the search is successful, the shell shall execute the utility with actions equivalent to calling the execl() function as defined in the System Interfaces volume of POSIX.1-2008 with the path argument set to the pathname resulting from the search, arg0 set to the command name, and the remaining execl() arguments set to the command arguments (if any) and the null terminator.

If the execl() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and the exec command shall fail with an exit status of 126.

It is unspecified whether environment variables that were passed to the shell when it was invoked, but were not used to initialize shell variables (see [xref to 2.5.3]) because they had invalid names, are included in the environment passed to execl() and (if execl() fails as described above) to the new shell.

b.

If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.

2.

If the command name contains at least one <slash>:

a.

If the named utility exists, the shell shall execute the utility with actions equivalent to calling the execl() function as defined in the System Interfaces volume of POSIX.1-2008 with the path and arg0 arguments set to the command name, and the remaining execl() arguments set to the command arguments (if any) and the null terminator.

If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and the exec command shall fail with an exit status of 126.

It is unspecified whether environment variables that were passed to the shell when it was invoked, but were not used to initialize shell variables (see [xref to 2.5.3]) because they had invalid names, are included in the environment passed to execl() and (if execl() fails as described above) to the new shell.

b.

If the named utility does not exist, the command shall fail with an exit status of 127 and the shell shall write an error message.

exec - execute commands and open, close, or copy file descriptors

exec - perform redirections in the current shell or execute a utility

exec [command [argument...]]

exec [utility [argument...]]

The exec utility shall open, close, and/or copy file descriptors as specified by any redirections as part of the command.

If exec is specified without command or arguments, and any file descriptors with numbers greater than 2 are opened with associated redirection statements, ...

If exec is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment. If any file descriptors with numbers greater than 2 are opened by those redirections, ...

If the result of the redirections would be that file descriptor 0, 1, or 2 is closed, implementations may open the file descriptor to an unspecified file.

If exec is specified with command, it shall replace the shell with command without creating a new process. If arguments are specified, they shall be arguments to command. Redirection affects the current shell execution environment.

If exec is specified with a utility operand, the shell shall execute a non-built-in utility as described in [xref to 2.9.1.2] with utility as the command name and the argument operands (if any) as the command arguments.

If the exec command fails, a non-interactive shell shall exit from the current shell execution environment; [UP]an interactive shell may exit from a subshell environment but shall not exit if the current shell environment is not a subshell environment[/UP].

[UP]If the exec command fails and the shell does not exit, any redirections associated with the exec command that were successfully made shall take effect in the current shell execution environment. [/UP]

If exec is specified with a utility operand:

1.

If the utility does not contain any <slash> characters and either the named utility is implemented as a shell built-in or a function of the same name exists, it is unspecified whether or not the shell executes the built-in utility or function. If it does, the execution shall be performed as described in [xref to 2.9.1.1] and the shell shall then exit from the current shell execution environment as if by executing the exit special built-in utility with no arguments. If the shell does not execute the built-in utility or function, it shall execute a non-built-in utility as described below.

2.

The shell shall execute a non-built-in utility as described in [xref to 2.9.1.2] with utility as the command name and the argument operands (if any) as the command arguments.

If the exec command fails, a non-interactive shell shall exit from the current shell execution environment; [UP]an interactive shell may exit from a subshell environment but shall not exit if the current shell environment is not a subshell environment[/UP].

[UP]If the exec command fails and the shell does not exit, any redirections associated with the exec command that were successfully made shall take effect in the current shell execution environment. [/UP]

If command is specified, exec shall not return to the shell; rather, the exit status of the process shall be the exit status of the program implementing command, which overlaid the shell. If command is not found, the exit status shall be 127. If command is found, but it is not an executable utility, the exit status shall be 126. If a redirection error occurs (see [xref to 2.8.1]), the shell shall exit with a value in the range 1-125. Otherwise, exec shall return a zero exit status.

If utility is specified and is executed, exec shall not return to the shell; rather, the exit status of the current shell execution environment shall be the exit status of utility. If utility is specified and an attempt to execute it as a non-built-in utility fails, the exit status shall be as described in [xref to 2.9.1.2]. If a redirection error occurs (see [xref to 2.8.1]), the exit status shall be a value in the range 1-125. Otherwise, exec shall return a zero exit status.

An application that is not concerned with strict conformance can make use of optional %g support known to be present in the implementation's printf utility by ensuring that any shell built-in version is not executed instead, and using a subshell so that the shell continues afterwards:

<tt>(exec printf '%g\n' "$float_value")</tt>

Therefore, shell functions, special built-ins, and built-ins that are only provided by the shell are not found.

Therefore, shell functions, special built-ins, and built-ins that are only provided by the shell are not found by this type of env implementation. However, env can be implemented as a shell built-in, in which case it may be able to execute shell functions and built-ins. An application wishing to ensure execution of a non-built-in utility can use exec in a subshell for this purpose.

None.

Since it is unspecified whether exec executes built-in utilities and functions, portable applications cannot rely on the use of exec in a subshell to bypass these and ensure the execution of a non-built-in utility. The only portable ways to ensure execution of a non-built-in utility are:

1. Include at least one <slash> in the command name.

2. Execute it via the env utility, while ensuring that a non-built-in version of env is used.

For example, the following function employs method 1 to execute a non-built-in version of any utility:

exec_non_built_in() (
    safe_exec() {
        case "$1" in
        (-*) exec ./"$@" ;;
        (*)  exec "$@" ;;
        esac
        exit # can only be reached if shell is interactive
    }
    case "$1" in
    (*/*)
        safe_exec "$@"
        ;;
    (*)
        case "$PATH" in
        (*[!:]:) dirs="${PATH}:" ;;
        (*) dirs="$PATH" ;;
        esac
        IFS=":"
        set -f
        for dir in $dirs
        do
            case "$dir" in
            ("") dir="." ;;
            (*/) dir="${dir%/}" ;;
            esac
            if test -x "$dir/$1" && test -f "$dir/$1"
            then
                unset IFS
                safe_exec "$dir"/"$@"
            fi
        done
        printf >&2 "%s not found\n" "$1"
        exit 127
        ;;
    esac
)

Method 2 reduces to method 1 applied to the env utility, but the search for the non-built-in implementation of env can be done at the time the application is configured and installed. This reduces complexity in the application itself, but at the expense of an extra exec() call when it uses env to execute a utility.

Therefore, shell functions, special built-ins, and built-ins that are only provided by the shell are not found.

Therefore, shell functions, special built-ins, and built-ins that are only provided by the shell are not found by this type of env implementation. However, env can be implemented as a shell built-in, in which case it may be able to execute shell functions and built-ins. For methods of ensuring execution of a non-built-in utility, see the APPLICATION USAGE section of [xref to exec].