Two very compelling arguments. I concur with both. -Chip-
On 7/3/08 13:50 Rick McGuire said: > 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 > > ------------------------------------------------------------------------- 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
