[ On Wednesday, February 9, 2000 at 18:02:52 (+0200), Lucio De Re wrote: ]
> Subject: Re: Shell behaviour regarding PATH
>
> On Wed, Feb 09, 2000 at 10:46:13AM -0500, Greg A. Woods wrote:
> > 
> > Huh?  If you type a '/' in the pathname then presumably you know that
> > you're using the current working directory if you type a relative path.
> > 
> Do I?  I think that's an artifice, and an ugly one, at that.

If you don't know that then you haven't read/understood the manual!  ;-)

> > If your scheme were used instead suddenly there'd be a major discrepancy
> > between the way relative paths worked when they were used as command
> > names and when they were used as arguments.  This would be very bad.
> > 
> Exactly the case where argv(0) is involved.  Why is that an acceptable
> exception only if there is no "/" in the name?

The exception is necessary in order to implement a sane way of dealing
with search paths in the face of allowing relative pathnames at the same
time.

The rule is very simple:  If there's a slash anywhere in argv[0] then
treat it as a relative pathname and do not apply the $PATH search
algorithm.  If there is no slash then search in $PATH.  If you allow any
slash in a $PATH search then you will not be able to specify a program
in a relative directory that is also in a $PATH directory without
specifying an absolute (fully qualified) pathname which would make the
behaviour of such relative pathnames very un-predictable and thus
dangerous.  It would be better to simply outlaw relative pathnames all
together (and always force $PATH searches for argv[0]) and I don't think
anyone will go for that!  :-)

> > There are no surprises here.  A relative path is a relative path,
> > whether it starts with "./" or not.
> > 
> Wrong.  "./abc" is an absolute path, "./" and "../" and their composites
> are abbreviations.

Sorry, but you're wrong.  Perhaps you don't understand the definition of
a "relative pathname" in the Unix sense.

Unless a pathname begins with a '/' it is a relative pathname and the
search always begins at the current working directory.  From intro(2):

     Path Name
             A path name is a NUL-terminated character string starting with an
             optional slash `/', followed by zero or more directory names sep­
             arated by slashes, optionally followed by a file name.  The total
             length of a path name must be less than 1024 (MAXPATHLEN) charac­
             ters.

             If a path name begins with a slash, the path search begins at the
             root directory.  Otherwise, the search begins from the current
             working directory.  A slash by itself names the root directory.
             An empty pathname refers to the current directory.

Perhaps the word "relative" should be added somewhere in that second
paragraph to beter define the meaning.  (eg. "the search begins relative
to the current working directory" and/or "Otherwise the pathname is a
relative pathname and the search")

> But typing "kfs/diskcmd" is not discouraged, it is in fact used extensively
> in commands.  And it means that to run "netscape" once when I log on, I
> don't have to either clutter the system directories or to put
> /usr/local/netscape in the PATH.  [[....]]

On Plan-9 someone has to bind(2) /usr/local/netscape to /bin if you
don't put it in $path.

Since Plan-9 doesn't have execlp() there is no path searching outside of
what's done in "rc" itself and thus it may make sense for "rc" to always
look for "kfs/diskcmd" in the directories specified in $path.  This is
totally irrelevant though because this is not the way Unix works because
Unix does have execlp().

> </usr/local/<applic>/{bin,sbin,etc,lib}> structure is a proverbial PITA
> and does horrendous things to the shell environment, including making it
> unreadable.

I agree!  :-)

> As I stated, "./" is an abbreviation, and in my book, it makes "./file"
> an absolute, not a relative name.  Just like "~/file", only somewhat more
> transparent (or is that opaque?  sometimes English defeats me totally).

I think once you integrate the defined meaning of "relative pathname"
into your understanding that you'll better understand why execlp() et al
must not search $PATH when a slash ('/') appears in argv[0].

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