Date: Wed, 01 Jul 2020 20:00:23 +0200
From: Andreas Schwab <sch...@linux-m68k.org>
Message-ID: <871rlvcdzc....@igel.home>
| But it also says:
|
| 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 the command is built-in, it can hardly not be found, so the first
half of that doesn't apply. All that's left is "executable utility".
That isn't actually defined anywhere, but "utility" is, and while it
excludes the special built-ins, everything else that can be run as
a command counts, including those that only make sense when built in
(like say, command).
bash
jinx$ echo $$
10628
jinx$ exec command echo hello
bash: exec: command: not found
jinx$ echo $$
10628
jinx$ exit
NetBSD (deliberately, as it is stupid) ignores the requirement that
all non-special builtns be also provided as commands in the filesystem,
if we had a /usr/bin/command (or something) I assume bash would have
run it (even though XCU 2.9.1.1 1.d says that "command" is one of the
magic builtins which should be run as the built-in without bothering
with a PATH search first).
Having said all this, do be aware that this is all relevant to the
current POSIX standard, the next version [probably] changes the wording to:
If exec is specified with a utility operand, the shell shall execute
a non-built-in utility as described in Section 2.9.1.6 with utility
as the command name [...]
It will also require interactive top level shells not to exit on
exec error,
[None of this is set in stone yet, and changes might still be made].
The first of those changes matches what most shells do (as I said earlier),
the second will require changes in most shells, which currently do exit
as the current standard requires.,
kre
