Robert Elz <k...@munnari.oz.au> wrote, on 17 Jul 2017:
>
> | > The issue here is purely where exec looks to find the command
> |
> | That is the question that was asked, but it has already been answered
>
> I am not 100% certain that really happened. There have been opinions
> offered, but until there is actual wording for the standard, it is
> not really answered.
Okay, here are my suggested changes.
On page 2397 line 76683 section 2.14 exec, change NAME from:
exec — execute commands and open, close, or copy file descriptors
to:
exec — perform redirections in the current shell or execute a utility
On page 2397 line 76685 section 2.14 exec, change SYNOPSIS from:
exec [command [argument...]]
to:
exec [utility [argument...]]
On page 2397 line 76687-76689 section 2.14 exec, change:
The <i>exec</i> utility shall open, close, and/or copy file descriptors
as specified by any redirections as part of the command.
If <i>exec</i> is specified without <i>command</i> or <i>arguments</i>,
and any file descriptors with numbers greater than 2 are opened with
associated redirection statements, ...
to:
If <i>exec</i> is specified with no operands, any redirections
associated with the <i>exec</i> command shall be made in the current
shell environment. If any file descriptors with numbers greater
than 2 are opened by those redirections, ...
On page 2397 line 76693 section 2.14 exec, append to the paragraph:
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.
On page 2397 line 76694-76696 section 2.14 exec, change:
If <i>exec</i> is specified with <i>command</i>, it shall replace
the shell with <i>command</i> without creating a new process. If
<i>arguments</i> are specified, they shall be arguments to
<i>command</i>. Redirection affects the current shell execution
environment.
to:
If <i>exec</i> is specified with a <i>utility</i> operand:
1. If <i>utility</i> does not contain any <slash> characters,
the specified utility 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
<i>execl</i>() function as defined in the System
Interfaces volume of POSIX.1-2008 with the <i>path</i>
argument set to the pathname resulting from the search,
<i>arg0</i> set to <i>utility</i>, and the remaining
<i>execl</i>() arguments set to the <i>argument</i>
operands (if any) and the null terminator.
If the <i>execl</i>() 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 <i>utility</i>. 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 <i>exec</i>
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 <i>execl</i>() and (if <i>execl</i>() fails as
described above) to the new shell.
b. If the search is unsuccessful, the <i>exec</i> command
shall fail with an exit status of 127 and the shell shall
write an error message.
2. If <i>utility</i> contains at least one <slash>, the shell shall
execute the utility with actions equivalent to calling the
<i>execl</i>() function as defined in the System Interfaces
volume of POSIX.1-2008 with the <i>path</i> and <i>arg0</i>
arguments set to <i>utility</i>, and the remaining
<i>execl</i>() arguments set to the <i>argument</i> operands
(if any) and the null terminator.
If the <i>execl</i>() 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 <i>utility</i>
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 <i>exec</i> 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 <i>execl</i>()
and (if <i>execl</i>() fails as described above) to the new shell.
When the shell performs the <i>execl</i>() actions described above, it
shall not create a separate utility environment (see [xref to 2.12])
for this execution; the new process image shall replace the current
shell environment. If the current execution 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.
If the <i>exec</i> command fails, a non-interactive shell shall exit
from the current execution environment; [UP]an interactive shell shall
not exit[/UP].
[UP]If the <i>exec</i> command fails and the shell does not exit, any
redirections associated with the <i>exec</i> command that were
successfully made shall take effect in the current shell environment.
[/UP]
On page 2398 line 76737 section 2.14 exec, add to EXAMPLES:
Execute the implementation's <i>printf</i> utility, 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>
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
