Re: external versions of sh built-in utilities

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> 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
built-in utilities")?
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?