On all the Unix shell platforms with which I am familiar, the current directory is searched for executable scripts IFF it is listed in the PATH variable, either explicitly or by default (i.e. the presence of an unnecessary ":" directory list delimiter). There is no specific search of the current directory at a different (especially earlier) point. From what I understand, this is a security issue.
I'm not sure how closely you want to mimic the underlying platform's search behavior (which could be a challenge on z/Series) but step 2 will be a surprise to Unix users, I would think. That aside, I agree that an application would prefer the predictable behavior of step 1, but such an application is surely capable of setting the (REXX)PATH such that its own directories are searched first. As a general design philosophy, the more fixed levels you introduce (e.g. steps 1 and 2) into a search scheme, the harder it is to override it when necessary. -Chip- On 7/2/08 18:45 Rick McGuire said: > As part of the recent merge back into the trunk, I introduced the > concept of an "extension path" as an option to the APIs. The intent > of this option was to allow the normal file search path to be extended > by an application. For example, the THE editor could add its macro > search path to the normal lookup order right up front rather than > relying on the function call exit to extend the search order. > > Part of my thinking here was the command launchers (rexx, rexxpaws, > rexxhide, etc.) would then use the new APIs and use the value of a > REXXPATH variable to extend the normal search order. However, the > more I think about it, the more I believe that applications like THE > would probably want the REXXPATH setting to be part of the normal > search order, and the API would be yet one more level on top of that. > It's a fairly trivial matter to add this extra level with the code we > currently have in trunk. > > So, this will make the search order for files to be: > > 1) The directory of the calling file (only for external function > calls), and only if the program was loaded from disk. > 2) The current directory > 3) The extension path > 4) REXXPATH > 5) PATH > > How does this sound to people? Should 1) and 2) be reversed so that > we always look in the current directory first? I can come up with > valid arguments each way, but if you're packaging a collection of > files as an application, you will get more predictable behavior if the > co-located files are picked up before whatever happens to be in the > current directory. > > Rick > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
