2009-09-22

strange (Open)Solaris PATH behavior

The PATH variable usually does not contain the . directory, which means files in the . directory cannot be executed without ./ afaik
$ cat w.cmd
who
$ PATH=/usr/bin
$ w.cmd
-bash: w.cmd: command not found

But then this happened on Solaris 10:
$ PATH=/usr/bin:
$ w.cmd
paul pts/2 Sep 22 20:20 (192.168.1.34)
$

Note the colon at the end of the PATH variable. I tested this in Solaris 10 and OpenSolaris, both in Korn and bash. Why does it allow execution from within the current directory ?
(This feature/bug does not work in Linux btw)

4 comments:

bert said...

Paul, AFAIK, this is standard behaviour at least in Bash (also on Linux). In de manpage van bash vind je onder andere dit over $CDPATH 'A null directory name in CDPATH is the same as the current directory, i.e., "." .' Dat is dus het gedrag dat jij ziet voor $PATH.

nxadm said...

You are comparing:
PATH=/usr/bin
with
PATH=/usr/bin:

So you indieed pass an empty string Path to the PATH variable.

C.

Paul Cobbaut said...

thanks

Ryan said...

From the POSIX spec...

"PATH
This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename. The prefixes shall be separated by a colon ( ':' ). When a non-zero-length prefix is applied to this filename, a slash shall be inserted between the prefix and the filename. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent colon characters ( "::" ), as an initial colon preceding the rest of the list, or as a trailing colon following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH . The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. If the pathname being sought contains a slash, the search through the path prefixes shall not be performed. If the pathname begins with a slash, the specified path is resolved (see Pathname Resolution ). If PATH is unset or is set to null, the path search is implementation-defined."


So it's intended, but legacy behavior. Strict compliance expects the '.'