Hi all, I'm copying the README.md from https://github.com/RexxLA/rexx-repository/tree/master/ARB/standards/work-in-progress/search-order/tests/programs/TestSearchOrder below
------------------- (cut) ---------------- Test Search Order A program to test the Search Order Features: - "Call Test" and then "Call 'test'" (allows to check for case-sensitivity) - See whether search is directory-first or extension-first (special tailored tests for ooRexx and Regina) - Same (caller) directory calls - Current directory tests - PATH directory tests (PATH is modified so that it has only one directory -- that's enough) - Downward-relative directory tests (i.e., "Call 'lib/test.rex'") - Dot-relative directory tests (i.e., "Call './test.rex'") - Dotdot-relative directory tests (i.e., "Call. '../test.rex'") To do: - There's a "debugLevel" variable in 'subdir/dotdotsame/same/main.rex' that allows control of verbosity. Change that to a program argument, expand and document. - In-program documentation. - Backslash-relative directory tests (Windows-only) (i.e., "Call '\some\path\test.rex'"). - Drive-relative tests (Windows-only) (i.e., "Call 'D:relative\path\test.rex'"). - Drive-absolute tests (Windows-only) (i.e., "Call 'D:\some\path\test.rex'"). - The three above, but with UNC "\server\share". - Add support for new interpreters. Works in - ooRexx (tested with 5.1.0 under Windows 11 Pro, but should work with other versions). - Regina (tested with 3.9.5 under Ubuntu 20.04 [wsl2], but should work with other versions). Downloads: - Here <https://github.com/RexxLA/rexx-repository/blob/master/ARB/standards/work-in-progress/search-order/tests/programs/TestSearchOrder/testsearchorder.zip> Installation and running the test: - Unzip testsearchorder.zip <https://github.com/RexxLA/rexx-repository/blob/master/ARB/standards/work-in-progress/search-order/tests/programs/TestSearchOrder/testsearchorder.zip> and execute testsearchorder.rex in the testsearchorder folder. ------------------- (cut) ---------------- You can download it here: https://github.com/RexxLA/rexx-repository/blob/master/ARB/standards/work-in-progress/search-order/tests/programs/TestSearchOrder/testsearchorder.zip I've summarized the results of these tests here: https://github.com/RexxLA/rexx-repository/blob/master/ARB/standards/work-in-progress/search-order/tests/results/Regina-vs-ooRexx.md -- I'd suggest you take some few moments to browse them. It's very illuminating to take a look at these results and at the comparison table. I'd say that *the idea that, regarding the search order, "there's a Rexx way of doing things", to be honest, is very difficult to sustain*. As you'll see, ooRexx and Regina have few points in common, and in essential aspects they go to opposite extremes. I don't want to copy the full comparison chart; I'll list only some few of these aspects. - ooRexx has a concept of "same" (i.e., caller) directory, Regina has not. - ooRexx traverses all the possibilities *extension-first*, Regina does it *directory-first*. - ooRexx searches for a file with no extension in the last place, Regina does it in the first place. - The built-in list of extensions to search is different in ooRexx and Regina. - ooRexx allows one to specify extra (non-PATH) paths, but these go after the current directory (and after the application-defined path list); Regina puts them before the current directory. - ooRexx doesn't allow the user to specify extra extensions (the application developer can specify them); Regina controls this aspect with an environment variable. Best regards, Josep Maria Blasco Missatge de Josep Maria Blasco <jose.maria.bla...@gmail.com> del dia dj., 9 de febr. 2023 a les 13:02: > Hi René, > > Thanks for your comments. I've been doing some tests under Regina (latest > version, under Ubuntu). Regina exhibits some striking differences compared > to ooRexx: > > - There's no concept of the "same" (or caller's directory). If you put > a routine R in the same directory as the calling program, you can't Call R > and expect it to work. > - The search order is (1) REGINA_MACROS (environment variable), (2) > current directory, (3) PATH (compare that to (1) caller's directory, (2) > current directory, (3) application-specified path, (4) REXX_PATH, (5) PATH > in ooRexx). > - If the program name "contains a file path specification", then the > search order is completely bypassed. Notice that this is much more > stringent than ooRexx: in ooRexx, you can Call lib/my.rex and expect the > search order to work, but in Regina the search order will be bypassed > because the program name contains a slash. > - This last point is *documented* in 1.4.2 (p. 15 of the 3.9.5 version > of regina.pdf): "Note that the search algorithm to this point is ignored if > the program name contains a file path specification. eg. if "CALL .\MYPROG" > is called, then no searching of REGINA_MACROS or PATH is done; only the > concatenation of suffixes is carried out." > - There is no notion of "same extension". If an extension is present, > only this extension is searched. Otherwise, "the file name is extended by > the extensions [1] "" (empty string), [2] ".rexx", [3] ".rex", [4] ".cmd", > and [5]".rx" in this order. The file name case is ignored on systems that > ignore the character case for normal file operations like DOS, Windows, > and OS/2." Please notice that the null extension (that is, no > extension) is the *last* one in the ooRexx search, but the *first* one > in the Regina search. > - The list of extensions is also different. Compare it to [1]".cls" > (for ::requires only), [2] the same extension, the application-defined > extensions, [3] ".rex" and [4] no extension for ooRexx. > - There is a REGINA_SUFFIXES environment variable. If present, its > contents are placed after the empty extension "". > - If I read the docs correctly, I get the impression that the search > order in Regina is *directory-first*, that is, all extensions are > tried in a directory, then all extensions are tried again in the next > directory, etc. ooRexx is *extension-first: *all the directories are > searched for a given extension, then all the directories are searched again > for the next extension, etc. > > All the points except the last one have been tried with a test program > that I will upload shortly somewhere, and post the URL here. I will also > try to prepare a comparison chart and a high-level description of the > different search algorithms, so that we can compare them thoughtfully. > > Re: BRexx -- Can somebody please point me to a precompiled version for > Windows, preferably the 32 bit version? I'd like to extend my test programs > to be able to work under BRexx too. > > Kind regards, > > Josep Maria Blasco > > Missatge de René Jansen <rvjan...@xs4all.nl> del dia dc., 8 de febr. 2023 > a les 12:37: > >> Hi Josep, >> >> thank you for this investigation which I am sure we all have read with >> great interest. >> >> On 7 Feb 2023, at 11:35, Josep Maria Blasco <jose.maria.bla...@gmail.com> >> wrote: >> >> Once more: I don't think there's a clear, evident way to settle this >> conversation. A *decision* has to be taken. And it has to be *explained* >> (i.e., >> documented) and, if possible, *justified*. The last part is optional, of >> course: one can define a language as one sees fit. >> >> The weight, if any, of my contribution, is only to emphasize two things: >> >> - Other languages tackle this problem in a particular, coincident way. >> - And that way is the most economic in terms of describing the search >> procedure. >> >> This does not mean that what I am proposing should be accepted. It's only >> my point of view. >> >> >> I think this needs to be well documented (for all platforms Rexx is >> running on, with additions for the oo variants. There is a new Rexx ARB >> starting up where work can be done to isolate the different components of >> the question where things are found - I think one of the most important >> questions one encounters when trying to make something non-trivial. >> >> There is the component of history - CMS and TSO were there before the >> DOS/OS2/Unix world. There is the language philosophy angle - other >> languages make choices the might not be the Rexx way (those full of curly >> braces or significant spaces), while on some platforms (NetRexx - Java) the >> choices of the latter are like gravity. >> >> One question that comes up is if you compared the way ooRexx 5.X does >> this to Regina, Brexx or OS/2. I think one of the things an extended >> standard document could do is to help describe this and propose a standard >> way of implementing this which is straightforward on >> Windows/Linux(including other Unix like platforms like macOS). >> >> It could be argued that this is not part of the language but of the >> implementation - but I am doubting that the documentation of a >> function(method) call or the CALL statement is complete without a >> specification where it finds what it calls. >> >> Economy in terms of describing - well, that is relative I think - the >> procedure for finding and overriding a BIF in VM at least requires a >> flowchart in the VM documentation (and the way Brexx does it is different) >> but it expresses a common goal of being able to override a >> built-in-function. In z/OS we have lpa (flpa, mlpa), link list, sysproc and >> sysexec concatenation (and the alt library) where a compiled Rexx program >> could live and I would not be able to economically describe that, but they >> are all there for a reason. >> >> Thank you again for bringing up this discussion. >> >> Could you mail me that zip file so I can put it somewhere where more >> people can look at it? >> >> best regards, >> >> René Jansen. >> _______________________________________________ >> 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
