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