Not quite. People find uses for these things, and as the SUS rationale points out, for
every potentially useless external equivalent of a (non-special) built-in command someone
has come up with an arcane actual use for it. Even "cd".
Oh, definitely. And if my bathtub had a built-in trumpet, I could
certainly find a use for it, too; but that doesn't mean it would make
sense, no matter whether or not it's written in an official
specification
for bathtubs.
The POSIX model is therefore that all non-special built-ins are also available
as executables; or, rather, that all of the standard utilities that are not
special built-ins are simply *available* (via execvp(), find -exec, env, and
*all of the other* ways that standard utilities can be invoked), and whether
they are built-in or not, to a shell or otherwise, is an implementation detail
as far as actually invoking the utility is concerned.
And I have no qualms about it for builtins that do something else than
just change the process state. But for a builtin that's supposed to only
change the process state, and whose use as an external program is
marginal at the very best, that model is terrible: it tries to make the
presence or absence of a shell undetectable (which it can never be), and
the consequences of that attempt leak outside of the legitimate domain
of the shell, and Dewayne's issue with umask is an illustration of this.
--
Laurent
