Chip,
I think somebody must have hacked into your email, because it must
have been someone else who stated:
Two very compelling arguments. I concur with both.
The last time this feature was discussed.
Rick
On Fri, Jun 26, 2009 at 5:11 PM, Chip Davis<c...@aviatrexx.com> wrote:
> 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
>
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
