[patch] bug #7 -- which(1) is b0rked

[Paul Fox]

 > >  > PS: please see the bug-comment wrt '::' and let me know if i should deal
 > >  > with it or not.
 > >
 > > i've added a note to the bug, which bernhard has probably seen by
 > > now, but for the list:  the issue is that "which" doesn't treat
 > > empty directories in $PATH as the current directory, and
 > > therefore won't always find executables that the shell would
 > > find.  PATH has always been interpreted this way by /bin/sh, as
 > > well as by bash.  (though the man page doesn't say so -- that's a
 > > serious omission, in my opinion).
 > 
 > When an accidental colon can put the current directory into
 > the path, and this fact isn't even documented anywhere, that's
 > a security hole waiting to happen.  We should not support
 > that.  We should _document_ that we don't support it, and we
 > should document that it's an undocumented "feature" in other
 > shells.

are you suggesting that we change all of the busybox shell code
to not handle this case?  like it or not, this behavior with
respect to PATH has existed forever.  it's part of execvp(), for
instance.

i completely agree that the existing behavior should be well
documented.  (in fact, i submitted a doc bug against bash
yesterday, when i went looking for justification for bernhard and
couldn't find it.)  i could even see justification for a
suppressable warning that you'd get if you use such a PATH
setting.  but i don't think we can really expect to "fix" the
problem.

 > 
 > If you want to put .  in the path, be explicit.  It's just 1
 > extra character.

like tabs in makefiles, some syntax decisions were made far too
long ago to be changed now.

paul
=---------------------
 paul fox, pgf at brightstareng.com