Subject: Shell behaviour regarding PATH
To: None <email@example.com>
From: Lucio De Re <firstname.lastname@example.org>
Date: 02/09/2000 13:09:17
I've raised this before, but I somehow wasn't convinced last time.
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. The search path is the path speci-
fied in the environment by ``PATH'' variable. If this variable isn't
specified, the default path ``/bin:/usr/bin:'' is used. ...
I'm not sure (I haven't looked at the sources) whether /bin/sh uses
exec(2) or viceversa, but the above behaviour has an unpleasant
side effects reflected in all common shells under NetBSD: if I type
"bin/prog", the assumed target is not one of the directories in
the PATH, but rather the current directory. 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. Even though it is a less likely weakness, this strikes me as
inappropriate and inconsistent.
2. This behaviour is identical to typing "./bin/prog" and therefore the
reverse is not available. In other words, I can override the PATH
selection by typing "./prog", thus being offered two distinct alternatives,
whereas the moment the name has a "/" in it, these options are merged
into an alternative I find unappetising, with no access to the
alternative. Even the law of least surprise is defeated by this.
3. I cannot adopt Plan 9's approach of using named subdirectories of
/bin to hold executables for various packages, which I find a very
sensible approach to organising a multi-platform environment. This
need not appeal to everyone, but in my investigations has stood up
best as a structure. Plan 9 is documented at
and despite some philosophical clashes with NetBSD, is also my
favorite model on which to base platform independence in a Unix-like
(By way of llustration, I may have installed a seldom used copy of
gmake: in Plan 9 I would type "gmake/make" to execute it, whereas
under NetBSD I have to use /usr/bin/gmake/make to achieve the same
result; if gmake/make becomes very popular, in Plan 9 I would union
mount /usr/bin/gmake on /usr/bin to override the standard make.)
4. I don't think that treating "bin/prog" as identical to "./bin/prog"
is semantically valid. Besides removing an option as mentioned
in 2. above, it is also inconsistent with the otherwise clear
distinction between "relative" and "absolute" pathnames. It is
my proposition that the exec(2) (and shell) implementation should
use this distinction, rather than the arbitrary _presence_ of
a "/" somewhere in the name to decide whether to search the PATH
End of rant. I am really curious to know whether most participants on
this list feel my arguments above are empty, and if so, why. And, yes,
I'll happily apply myself to changing the behaviour, if I can be sure
that I don't have to repeat these changes every time an upgrade occurs.
As for borrowing the directory hierarchy from Plan 9 "lock, stock and
barrel", I'm waiting for the bugs to be ironed out of the "union"
filesystem (_that_ bit I haven't the skills and time for) before
embarking on an _alternative_ hierarchy campaign. My hope is to be
able to choose at installation time which of two conventions to adopt
and to make sure they are both equally workable. But not just yet :-)