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

> [I]f I type "bin/prog", the assumed target is not one of the
> directories in the PATH, but rather the current directory.

Yes.  It has worked this way since long before NetBSD.

I too find this unpleasant; one of the things I added back when I was
hackign on csh was a feature whereby if you `set slashpath' then the
"if...does not contain a slash" check is suppressed.

> There are many aspects of this behaviour I dislike to the point that
> I consider them harmful:

> 1. This defeats the protection afforded "root" by not including "."
>    in the PATH.

Only if the admin uses relative pathnames like bin/prog expecting them
to be interpreted relative to $PATH directories.  The point of not
having . in the path is to avoid tripping over trojans (malicious or
accidental); if the admin's brain does not expect $PATH searches for
command names containing slashes, there is no problem.

> 2. This behaviour is identical to typing "./bin/prog" and therefore
>    the reverse is not available.

Right.  This is arguably a problem, and the only fix I can see is to
make the shell (whatever the shell in question is) special-case command
names beginning with "./".  Certainly as far as pathname interpretation
goes there is no particular difference between ./foo/bar and
one/two/three - they're both three-component paths relative to the
current directory.

> 4. I don't think that treating "bin/prog" as identical to
>    "./bin/prog" is semantically valid.  Besides [...], it is also
>    inconsistent with the otherwise clear distinction between
>    "relative" and "absolute" pathnames.

What are you on and where can I get some?  Both bin/prog and ./bin/prog
are perfectly good relative paths, relative to the process's current
directory.  That one begins with the somewhat special component "." has
little to nothing to do with that.

Greg Woods responds

> Read again the part that says "if the specified file name does not
> contain a ``/'' character."  I.e. the searching feature is not
> available at all for your example, and for good reason!

It seems to me that the original post made it clear that this was
exactly what the poster perceived as a problem and thus wanted to fix.

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

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.

>> 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". :-)

And in another message,

> 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

True.  This is one of the reasons that a user may choose not to enable
$PATH searching for command names containing slashes.

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

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.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B