[ On Thursday, February 10, 2000 at 07:57:16 (+0200), Lucio De Re wrote: ]
> Subject: Re: Shell behaviour regarding PATH
>
> Well, execlp() is obviously not used in /usr/pkg/bin/rc as supplied in the
> packages collection, and I can cope quite well with that :-)  I should
> suggest we add exec?pr(2) to implement a PATH behaviour analogous to rc's.

I think that would be a bad idea.  It's one thing to use pkgsrc/plan9/rc
for Plan-9 buffs who are knowledgable about the differences inherent in
having a different handling of search paths and perhaps there could even
be a pkgsrc/plan9/execvp for real die-hards who have to use Unix but
would rather be using Plan-9.

However I think this is a very slippery and steep slope.  You do not
want to introduce this kind of thing for naive users or you will confuse
the heck out of them because then you'll end up with both variants of
behaviour.  Plan-9 was right to totally erradicate execvp() and strongly
discourage extension of $path beyond ".:/bin" when allowing relative
paths for argv[0].

> I do maintain, though, that the difference is sufficiently subtle as to
> fool even a sophisticated user, and that the alternative is more
> consistent and more practical without being totally disruptive.  I was
> however curious about the origin of the confusion (Stephen Bourne?) and
> the ramifications of a possible change.

I think better documentation of relative pathnames in conjunction with
the meaning of the aliases for the current and parent directories, and
more widely distributed mention of the way $PATH searches are avoided
when any '/' exists in argv[0] regardless of whether it's a relative
pathname or not.

I'm not sure when or who made the decision to implement $PATH searching
the way it was done.  The V7 sh(1) manual says:  "If the command name
contains a / then the search path is not used."

-- 
							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>