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
