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
