Date: Wed, 26 Jul 2017 00:00:16 +0000 (UTC)
From: Thorsten Glaser <tg...@mirbsd.org>
Message-ID: <pine.bsm.4.64l.1707252357190.2...@herc.mirbsd.org>
| Thereâs no âexecâ system call, so thatâs the wrong part
| youâre searching in for this.
It is the part that is referenced in the section that you quoted.
You can view it at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
The title (for the index) is "exec" - it describes
environ, execl, execle, execlp, execv, execve, execvp, fexecve -- execute a file
XCU 1.6, that you quoted from (XCU is the "Shell & Utilities" volume)
refers to the page at the URL above, for the purpose of requiring that
all (non-special) builtins be able to be exec*()'d (using whichever
of the exec family of system calls ("system interfaces") you prefer.)
| Yes, that *too*, but it also says that they *may* be builtins.
Yes, anything can be (a masochist could build in gcc if they wanted)
but that's not really material to the question.
| 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."
| 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
