$PWD

[John Chambers,,,781-647-1813]

Christoph writes:

| - Christoph
| John Abreau wrote:
| > On Wed, 28 Jul 1999, Subba Rao wrote:
| > 
| > > Thank you for replying. Is this a BASH shell feature?
| > > 
| > 
| > No, this is more basic than that: it's part of how PATH is defined. All
| > shells are required to parse PATH in this manner.
| > 

| There you go!  You learn something everyday...  I did not know this
| bit about PATH parsing.

Yup.  Who does it can be inferred by looking up the  various  exec*()
man  pages,  and noting that some of them (such as execvl and execvp)
use the PATH environment  variable  to  look  up  the  program  being
exec'd.   This  implies  that  all  programs  that use these routines
(including possibly indirectly via calls on other C library routines)
parse  and understand the PATH variable the same way.  Any C programs
that use these calls will use PATH exactly like  shells  do,  because
they're all passing the parsing off to the same C library routine.

There have even been some unices that have this  parsing  inside  the
kernel.   You can spot this by testing to see whether scripts require
the full path on the #! line. Some systems allow you to say #!foo and
foo  will be looked up in the PATH.  Since parsing the #! line pretty
much has to be done by the kernel's exec routine (otherwise there's a
race  condition  that's a serious security problem), when #!foo works
it implies that the PATH parser is linked into the kernel.  But #!foo
usually  doesn't  work,  because  PATH is only parsed inside the libc
routines and these aren't in the kernel.

(It's really handy if #!foo works.  Is there a way to get linux to do
this?)

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).