Chip has a good argument, and I almost considered implementing it this way. However, I prefer to think of these as the "Rexx" lookup rules rather than the "platform" lookup rules. In other words, it's better to have a standard set of Rexx rules that can be depended upon from platform to platform than to necessarily modify this for a given platform just to make it different. People complain the most about differences in behavior when they move programs between platforms.
However, there's an even bigger reason to include the current directory in the search...we're already doing it that way in all of the existing releases. It's one thing to be different between platforms, it's another to decide to intentionally break compatibility without an extremely good reason for doing so. Rick On Wed, Jul 2, 2008 at 4:27 PM, Chip Davis <[EMAIL PROTECTED]> wrote: > 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 > suc > 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 > ------------------------------------------------------------------------- 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
