Hi Josep Maria,

On 05.02.2023 15:17, Josep Maria Blasco wrote:
Missatge de Rony G. Flatscher <rony.flatsc...@wu.ac.at> del dia dg., 5 de febr. 
2023 a les 13:29:

... cut ...

    Not being the expert in this corner a question to you as you have developed 
a deep insight in
    the meantime: while developing on json.cls there are two json.cls present 
at the moment
    (Windows layout):

        C:\Program Files\ooRexx\json.cls
        C:\Program Files\ooRexx\rexxtry.rex

        F:\work\svn\oorexx\sandbox\rony\json\json.cls

        current directory is: F:\work\svn\oorexx\sandbox\rony\json

    Now while doing interactive tests via rexxtry.rex (i.e. "C:\Program 
Files\ooRexx\rexxtry.rex")
    doing a "call json.cls" will find and call "C:\Program 
Files\ooRexx\json.cls" and *not*
    "json.cls" in the current directory!

Sure :) Rexxtry.rex is in the "C:\Program Files\ooRexx" directory. This is the "same" directory of the docs, or the "parent" directory of the source (I'd prefer to call it the "caller's" directory, I think it's a more accurate description; but I disgress). "Call json.cls" is one of the cases where Rexx works as documented. And the search order begins... by the "same" directory, as per the docs. That's why the version in "C:" is called.

    However, in the same rexxtry.rex session in the current directory doing a "call 
.\json.cls"
    *will* resolve and call "F:\work\svn\oorexx\sandbox\rony\json\json.cls": so 
"." will force
    using the current directory for finding external Rexx programs.

That's exactly our bug.
Hmm, maybe it is not a bug after all, but working as intended as this allows for overriding the default search order that starts out in the source directory (the directory the Rexx script got loaded and run from as in the case of rexxtry.rex, doing a "parse source . . path2source" would denote the Rexx program's source directory.)

If I understand you properly, the only difference between this last test and the previous one is the addition of ".\". This is, precisely, one of the cases where what Rexx does and what's in the docs /differ/. ".\" should mean "in /this/ directory". But what does "this" mean, i.e., "this" relative to what?
Probably "the current directory".

Well, according to the docs, we have to respect the search order. And, in the first place... "this" should be relative to the "same" directory, that is, the very same "same" directory (sorry). That's the caller's directory, that is, where rexxtry resides. BUT... here's this bug we are talking about: since the callee's filespec begins with ".\", the search path is bypassed (it should not be!). This means that the filespec is resolved (more or less) like in the command line (to be true, the resolution mechanism provided by the SearchPath Windows API --what Rexx for Windows uses-- differs from the command line one, with the clear intention to get the programmers and users altogether completely braindamaged, I'm obliged to presume). But when you're in the command line (and, in this case, when you call SearchPath), "." means the /current/ directory, not the /same/ or caller's directory. Hence, the F: version of json.cls gets called.

This was actually the intention when doing a 'call ".\json.cls"', to override "json.cls" in rexxtry.rex' source directory. What would you suggest to use instead, a fully qualified path to ".\json.cls" (which one could hardly hard code in advance)? Maybe I have myself not fully understood all the ramifications of what you suggest, or why you would regard 'call ".\json.cls"' resolving the file in the current directory would be an error (for Rexx that is).

If you had instead tried "Call C:json.cls", you'd have had the C: version called. This is maybe the easiest way not to get lost: "Call C:json.cls", and "Call F:json.cls". Of course, the current directory of C: /and/ of F: have to point to the right places.

    So it seems that removing "." may have side effects that are not (yet) 
covered by the test cases?

To the contrary: if you had tried the Ubuntu version of the interpreter after having applied my patch (https://sourceforge.net/p/oorexx/bugs/1865/?limit=25#687f), then "Call json.cls" and "Call ./json.cls" would have had the same effect. As one would expect, both would have called the version in the /same /directory. To call the version in the /current/ directory without using a complete, absolute path, you'd have had to resort to F:json.cls or the like :)

If possible the lookup should work the same on Unix and Windows such that a Rexx programmer would not have to worry on which platform the program gets run.

Personally I never use relative file paths if not absolutely necessary (and very rarely so, hence being more than rusty by now!). Rather than using relative paths in the Rexx programs I would adjust the PATH environment variable such that the desired search order is reflected via it and then start the Rexx program in that environment.

If you look up the test framework and how to get to its Rexx packages/programs that is exactly what "setTestEnv.bat" (Windows) and "setTestEnv.sh" (Unix) do in "test/trunk". That is the reason why only unqualified file names are needed in all requires directives in the entire test package.

But again, I am no expert her, so hoping that Rick or Erich can shed some more 
light on this.

Best regards

---rony

_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to