Subject: Re: Shell behaviour regarding PATH
To: Greg A. Woods <email@example.com>
From: Lucio De Re <firstname.lastname@example.org>
Date: 02/11/2000 17:29:32
** offline **
On Fri, Feb 11, 2000 at 10:05:19AM -0500, Greg A. Woods wrote:
> [ On Friday, February 11, 2000 at 02:12:35 (-0800), Todd Whitesel wrote: ]
> > It is how you implement a command line that accepts either commands or
> > pathnames to programs, with no ambiguity between the two unless you
> > deliberately add "." to your PATH.
> Not to go on too long, but yes, I agree 100%! :-)
I actually admitted to Todd that I don't understand what he's saying,
so I can't exactly argue with your agreement.
> In fact I was quite surprised after thinking things through in this
> context that "." was in fact a part of the default search path for the
> Plan 9 "rc" shell. I fully expected it to be just "/bin" until I read
> to the bottom of the manual page this time. I guess old habits die
> hard! :-)
No "root", no need to bypass the current directory. And a real need, in
the Plan 9 context, to include the current directory for traditional
> I've almost given up on putting "." (or rather an empty sub-field) in my
> $PATH on Unix too, and I've been recommending the same to new users of
> Unix that I've been helping too. I find they have a much deeper
> understanding of $PATH and relative pathnames if they learn to always
> use "./foo" when they mean to run something locally. It also saves from
> having to explain to them why "test" won't run their local "test"
> program -- they figure that out naturally on their own if they
> understand the basics and knowing that they figured this out on their
> own is even more important to their learning.
And then they go and type "foo/bar" and the current directory nabs them.
I think my point - or rather, Plan 9's - is still valid :-)