Re: sh: utilities implemented as a built-in

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 24 Mar 2017 12:09:03 +0100
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <20170324110903.GB43723%trav.math.uni-bonn.de@localhost>

  | Do you know of any shell that actually complies to that part of POSIX?

No, not to that extent - ksh93 is supposed to be closest.

You could try ast-ksh from pkgsrc/shells if that is building these days.

  | Hm. What's the point of (assuming [ being implemented as a built-in)
  | 	PATH=/nonexistant true
  | to succeed and
  | 	PATH=/nonexistant [ 1 -eq -1 ]
  | to fail?

Accident of history?    But no, there's no good reason at all for true/false
to be considered as "known" built in, they should be removed from that list.
But in ksh ...

Incidentally, the reason that the path search stuff isn't completely
absurd, is that if I have PATH=$HOME/bin:/bin:... (which is more or
less what I do) and I decide to implement my own (improved) test, or '['
command (or probably, both) and install it in $HOME/bin I'd really like
(and expect) it to get used, rather than the /bin/test (/bin/[) clone
which is built into the shell.  That's what would happen for "ls" or "cat"
or any other command not built in.   Currently it doesn't work for built-ins
without one form or other of extra magic to cause it.

  | Would it make sense for command -V et al to call (regular) built-in
  | utilites ``regular'' and omitting that word on utilities implemented
  | a a built-in?

It might, but probably only if it were to make some actual difference,
rather than just being an artifact of thw way posix is written.   Currently
in our shell there is no difference (in form, not actions of course) between
true and test, they're both implemented in the same way (with different code).
So, doing something to differentiate them would just be a hack.

kre