David -
I'm afraid your example does not demonstrate the mechanism. Try:
[dash...@localhost ~]$ ad/prototype.rex
and see if it finds the executable without the current directory being in the
PATH variable.
In your example, the shell knows that '.' is a pseudo-directory entry found in
every directory, which points to the inode of the directory it's in (a "here
pointer"). It's the same sort of directory entry as '..' which points to the
inode of the parent directory of the one it's in. This can be verified by
inspecting the output of 'ls -lai'.
The shell knows that it can construct absolute paths from the '.' and '..'
tokens, and provides a few of its own like '~' and a few variants. These are
shortcuts for absolute paths, and the shell substitutes them into the otherwise
relative path you specified on the command line.
For example, if your current directory was '/home/dashley/foo/bin' and you
issued '../../ad/prototype.rex' the shell would have found it without
consulting
the PATH variable.
The same thing would happen if you issued: '~/ad/prototype.rex' from your
username from any directory on the system. Or '~dashley/ad/prototype.rex' from
any username anywhere on your system.
Technically, all of the above are examples of specifying an absolute path,
despite the fact that some of them do not start with a slash.
When the shell has enough information from the command line to generate an
absolute path, it does not refer to the PATH variable.
I was going to describe that mechanism in my original post but I thought that
such shell shortcuts were already understood. My major point was that MS-DOS
unilaterally and automatically adds the current directory to the PATH search
list, doing so in the worst possible position for security, reliability, etc.,
and leaving no way to un-include the current directory from the PATH. And now
ooRexx is making the same mistake.
-Chip-
On 6/26/09 18:10 David Ashley said:
> Chip -
>
> That is not correct, at least not on Linux as the following shows.
>
> [dash...@localhost ~]$ echo $PATH
> /usr/lib/qt-3.3/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibm/c4eb/bin:/home/dashley/bin:/usr/kerberos/bin
> [dash...@localhost ~]$ pwd
> /home/dashley
> [dash...@localhost ~]$ ./ad/prototype.rex
> return type = int *
> function name = fname
> arg 1 type = int
> arg 1 name = arg1
> arg 2 type = char *
> arg 2 name = arg2
> arg 3 type = long *
> arg 3 name = arg3
> [dash...@localhost ~]$
>
> The /home/dashley subdir is not in the PATH but the program was found.
> Thus a relative path does not have to have its root path in the PATH.
>
> David Ashley
>
> Chip Davis wrote:
>> On 6/26/09 16:05 Mark Miesfeld said:
>>
>>> On Fri, Jun 26, 2009 at 8:49 AM, Rick McGuire<object.r...@gmail.com> wrote:
>>>
>>>>> So the bug is that it is found on Windows. The bug is not that it
>>>>> should be found on Linux.
>>>>>
>>> Well, I only called it a bug on Windows because his example fails on 3.2.0.
>>>
>>
>> Not to be pedantic, but one could make the case that it _is_ a bug in
>> Window,
>> albeit a long-standing one.
>>
>> In Linux/UNIX, a relative-path command will not be found unless its
>> directory
>> was specified in the PATH variable. The current directory could be
>> specified in
>> the PATH with a dot or an extraneous delimiter (':') but is not required.
>>
>> If the current directory is not specified, it is not searched for a
>> relative-path command. This is useful when it was necessary to restrict the
>> directories from which commands can be issued.
>>
>> There are many ways to get malware onto a naive user's current directory, so
>> it
>> is strongly recommended that if the current directory is in the user's PATH,
>> it
>> should be at the end, and thus the last directory searched.
>>
>> MS-DOS (a re-implementation of UNIX for the PC) not only automatically
>> included
>> the current directory in the PATH (hey, it's more convenient) but put it at
>> the
>> beginning (hey, it's marginally faster). Which made it trivially easy to
>> lure a
>> naive user to a directory, whereupon he issues 'dir' which invokes a local
>> executable that does bad things.
>>
>> The UNIX/Linux approach provides a mechanism to prevent picking up
>> executables
>> from the local directory. The Windows, and now ooRexx, approach do not.
>> More
>> importantly, there is no way to override the ooRexx search order if the user
>> has
>> need to.
>>
>> -Chip-
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
