Re: sh: utilities implemented as a built-in

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

    Date:        Fri, 24 Mar 2017 14:07:27 +0100
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <20170324130726.GD43723%trav.math.uni-bonn.de@localhost>

  | Are we talking past each other?

Perhaps.

  | What I find absurd is what POSIX mandates and 
  | no shell known to me actually implements:

That's not good, and should be fixed (and there is definitely an issue
related to this that is being discussed ... slowly) but that's just
normal standards error, not actually absurd.   Mistakes happen.

  | if foo is implemented as a built-in
  | ---note that, in POSIX speak, that's different from foo being a (regular) 
  | built-in utility---, then choke if foo is not found in PATH, but if it is, 
  | use the built-in implementation anyway.

The idea behind this is that if (for example) test is implemented as
a builtin, as a clone of /bin/test, and then you remove /bin/test then
the builtin should go away as well.   That's actually not an unreasoable
goal.

However, I agree that attempting to legislate via standardisation is wrong,
and the standard should be describing what actually happens in existing
shells (or at the very least, in one of them) rather than what someone
wishes it would work like.


Joerg Sonnenberger <joerg%bec.de@localhost> said (about implementing [ in $HOME/bin):

 | Make [ an alias to the full path.

Yes, that works (though there's a good chance aliases might be removed
from the standard sometime in the future - their specification and 
implementation is weird, and they are not really needed for anything.
This wouldn't prohibit their existence though).

The problem with this solution is that it requires modifying every script
that uses '[' to add the alias command.   That's unreasonable.   That's also
the problem with most of the other (not implementing things the way the
posix spec says it should be done, even though it almost never is) possible
solutions.   There's no simple "set X in the environ" solution, the way
"set PATH" works (or is specified to work, but doesn't).

joerg%bec.de@localhost continued:
  | From a pkgsrc perspective, I really strongly want to keep the amount of work
  | necessary for the extremely common builtins down to a minimum. Having to
  | search path seems like a lot of unnecessary work.

I understand, but I don't think you'd normally notice the difference.
The directories in PATH all end up in the shell's hash table anyway, it
doesn't really matter whether that gets built on the first invocation
of '[' or the first invocation of make or cc - or just when PATH is set
at shell startup - building it is the same amount of work.  Once the hash
table is built, everything gets searched in their first, so I doubt you'd
be able to measure the difference in execution speed on anything real.
(The shell is not required to, and doesn't unless told, notice that a new
command appeared earlier in PATH than another command of the same name
that is later in PATH - it can keep on executing the older one, until
something resets PATH.)

Of course, if pkgsrc were written in sh rather than in make, all this would
be even less of an issue (there would be far fewer shell startups to have
to initialise stuff.)

kre