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
