[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: external versions of sh built-in utilities
> This leads to the crux of the matter - I have been told that POSIX
> actually requires that all of the commands in this third category (actually
> all the sh built-in commands, except the special built-ins) have an
> executable that can be subject of an execvp(2) call. The second group
> already have that, so it is only the third that matter here.
Are we talking about (in POSIX speak) "utilities implemented as a built-in"
(as opposed to "built-in utilities" -- which, in turn, differ from "special
Examples of special built-in utilites are break, return.
Examples of (regular) built-in utilities are true, cd.
Examples of utilities implemented as a built-in may be echo, printf.
I don't know all of SUSv4tc2 by heart, but the relevant part seems to be
2 Shell Command Language, 2.9 Shell Commands, 2.9.1 Simple Commands,
(unnumbered) Command Search and Execution, and then
-- 1.d. for built-in utilites
-- 1.c/1.e.i.a for utilities implemented as a built-in
For (regular) built-in utilities (e.g., cd) I don't see a requirement in 1.d
for an executable in PATH.
For utilities implemented as a built-in, 1.e.i.a demands the built-in only
be used if the path search is successful. A successful path search is defined
by "an executable file found", which may refer to the x bit set or "actions
equivalent to the execl() function" to succeed (where the distinction is
irrelevant due to /usr/bin/printf meeting both requirements).
Or are you talking about something completely different? Or a newer SUS?
Main Index |
Thread Index |