[ On Wednesday, February 9, 2000 at 14:11:49 (-0500), der Mouse wrote: ]
> Subject: Re: Shell behaviour regarding PATH
>
> > From the exec(2) man page:
> 
> >      The functions execlp() and execvp() will duplicate the actions of the
> >      shell in searching for an executable file if the specified file name does
> >      not contain a slash ``/'' character.
> 
> ...of course, they don't say *what* shell.  There is no `the shell',
> especially these days.

Now now!  :-)  There almost always has been, and still is, only one true
"Unix shell" (at least since V7).  POSIX continues this tradition.  All
non-Bourne-compatible shells are never referenced in the official system
documentation.  (Just as in Plan-9 there is only "rc" as the official
"command language", no /bin/sh.)

> There *already is* such a discrepancy.  Try "file file" sometime and
> notice that the "file" command name is path-searched (typically to give
> /usr/bin/file) but that the argument isn't.  All this is suggesting is
> changing this slightly, by removing the distinction between names
> containing slashes and names not containing slashes.  The current
> standard behavior exhibits the inconsistency when the name does not
> contain a slash but not when it does.

Strictly speaking the only inconsistency is the $PATH search in the
first place, which is probably why it was deprecated in Plan-9.  However
we're stuck with $PATH in Unix for a long time yet.  Given this
requirement for handling $PATH the current standard documented behaviour
of execvp() et al is the best compromise as it introduces the least
surprise -- i.e. the only objects searched in a $PATH are those with no
additional pathname components (no '/').

> >> 3. I cannot adopt Plan 9's approach of using named subdirectories of
> >>    /bin to hold executables for various packages,
> > Although the plan-9 approach has its advantages it simply cannot work
> > with the PATH scheme of Unix shells,
> 
> Right.  This is what the orginal poster was proposing to change - and
> what I already have changed, if I "set slashpath". :-)

Actually you'd have to make your change in src/lib/libc/gen/execvp.c if
you wanted to maintain any consistency with the rest of the system, as
well as in any shell that didn't ultimately use execvp().

> > which would make the behaviour of such relative pathnames very
> > un-predictable
> 
> Unpredictable?  Not at all.  Perhaps not what you're used to, but it's
> entirely predictable.

Well, yes, it's algorithmically predictable, but to the user who simply
does "mkdir foo; echo "echo hello world" > foo/bar; foo/bar" there's no
telling whether or not some "foo/bar" exists elsewhere in some directory
in his or her path until it is actually tried to do it, or until they do
some test to see if they're creating a naming conflict or not.  At least
now you know you're not searching other sub-directories when you put a
'/' in your command name.  The simple example is obviously "./test".  I
realize that "./foo/bar" solves the previous case too, but there's a
fundamental difference in that the former is long tradition and the
latter would be un-expected by users.

> Unless, I suppose, you're just unable to get your mental model unstuck
> from its current state...in which case it *is* unpredictable, for you,
> and hence you don't want to turn that feature on.

User's are already confused by naming conflicts when "." doesn't come
first in their $PATH.  Adding relative sub-directory searching to $PATH
searches would, from what I've seen in my experience, cause major
confusion.

In any case I think this particular issue is so firmly encoded in both
tradition and history, as well as in widely accepted standards, that
it's pointless to even discuss the possiblity of changing it within this
context.  If you want Plan 9 (as I sometimes do too!), then you know
where to find it, but don't expect such deep concepts to be changed in
Unix.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>