Robert Elz wrote:
| Note that the exec built-in utility does not need to perfom
| an exec*() system call.
Again, that is the question, perhaps it was meant to do that, but
the text just wrote it in a convoluted way in an attempt to avoid
requiring a specific implementation - but to many people
"replace the shell with command without creating a new process"
is just standards speak for "do one of the exec sys calls."
----
If you are executing a command or a function, they should behave
somewhat the same from the standpoint that in some cases functions
replace external commands for speed or portability. To remove that
use case, seems like removing a fundamental reason for builtins and
functions.
Suppose it is the case that either builtins or functions replace
external utilities on some distribution or, *especially*, an emergency
or recovery disk.
One wouldn't want things to act differently just because it was
changed to a builtin or function.
The shell can be replaced with a builtin or function -- that _exit_
when done. I.e. exec replaces the normal shell with the named
builtin or function by calling either of them in a context that is
followed by an exit. You've executed a "new program" (that doesn't
function like the shell), which has the behavior of the builtin
or function and then exits when done.
You *can't* call an external builtin or function when calling 'exec' but
call a different one in other areas for the main reason being that
builtins and functions may easily be replacing deleted external functions.
Therefore when 'exec' is executed with a builtin or function, I'd see
it replacing the shell (as characterized by its normal function), with a
call to the "internal" (builtin or function) command followed by an exit.
I feel that would provide the least surprises, and most portability between
different environments.
Since the above "stance" would put new work on some shells, I'd like
to recommend that the above behavior be standard for new implementations
after its approved as such, with a note that it would become a
requirement for existing shells by 2020/1/1(?) -- some future date
to allow, hopefully, unrushed time for implementation...(?)
| Of course you do, see the definition of “command†near the
| top of the shell section.
It has already been agreed that "command" was a bad word choice for exec,
and that (while it was certainly meant just as an English word, just
as we say the "ls command") the standards weasel word for what it means
is "utility" (the same as find can -exec utility, as can xargs, ...)
Don't read anything into the use of that word.
Personally I remain somewhat on the fence in this whole issue, apart
from not wanting to require that the shell be able to "exec func", or
"exec built-in" I don't currently really have an opinion on any of this.
That is, I don't object to shells that allow that, nor to shells that
want to build-in env, and allow env to run other built-ins or functions
(that one I think more useful than exec of a built-in) but I would not
want to require that either. And of course, any script that relies upon,
or even uses, any of the "unusual" variants of any of this is horribly
non-portable.
kre
