On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
> Greg Wooledge wrote:
> >Any pathname that contains a / should not be subject to PATH searching.
> You are alone in this opinion -- as most application don't follow that rule.
??
> Try 'C', if you include a include file with "/", it scans for it in each
> .h root.
C does not use the PATH variable to look for #include files.
> Try Perl -- same thing.
I'm pretty sure perl does not use the PATH variable to look for whatever
it is you're talking about.
> Try 'vim' -- same thing.
I'm pretty sure perl does not use the PATH variable to look for whatever
it is you're talking about.
> Almost all normal utils take their 'paths to be the 'roots' of
> trees that contain files. Why should bash be different?
Because we are not discussing Bash out of context. We are discussing
the PATH environment variable, which is used by the entire operating
system right down to the very kernel.
The PATH environment variable is ONLY used when the pathname to be
resolved does not contain a / character.
> It goes against 'common sense' and least surprise -- given it's the
> norm in so many other applications.
You are entirely wrong. But wait, there's documentation as well:
PATH The search path for commands. It is a colon-separated list of
directories in which the shell looks for commands (see COMMAND
EXECUTION below).
COMMAND EXECUTION
After a command has been split into words, if it results in a simple
command and an optional list of arguments, the following actions are
taken.
If the command name contains no slashes, the shell attempts to locate
it. [...]
If the name is neither a shell function nor a builtin, and contains no
slashes, bash searches each element of the PATH for a directory
containing an executable file by that name. [...]
If the search is successful, or if the command name contains one or
more slashes, the shell executes the named program in a separate
execution environment.
