*[Bringing the discussion from the RexxLA list, as per Rony's suggestion]* *Summary*
- The discussion initiated in this RexxLA thread: https://groups.io/g/rexxla-members/topic/the_external_program_search/96286751 , - then moved to https://groups.io/g/rexxla-members/topic/getting_oorexx_docs_test/96398260 - and finally to https://groups.io/g/rexxla-members/topic/next_steps_testing_patch/96697943 - A good description of the problem can be found here: https://groups.io/g/rexxla-members/message/947 - A preliminary test can be found here: https://groups.io/g/rexxla-members/message/954 - Another, quite exhaustive, review can be found here: https://groups.io/g/rexxla-members/message/956 I've opened a bug report: https://sourceforge.net/p/oorexx/bugs/1865/ ; Erich observed there some interesting details about the behaviour of the SearchPath Windows API. I submitted a patch for the docs, as a first draft to comment; https://sourceforge.net/p/oorexx/patches/218/ *Present* Yesterday I submitted a patch for CALL.testGroup: https://sourceforge.net/p/oorexx/patches/219/ (will submit an updated version, which addresses some problems, later). Yesterday I also had the opportunity, after some stimulus by Rony, to try my first compilation of the interpreter (under Ubuntu 22.04 --- wonderfully easy, btw). *Interesting news* If in platform/unix/SysFileSystem.cpp we change return name[0] == '~' || name[0] == '/' || (name[0] == '.' && name[1] == '/') || (name[0] == '.' && name[1] == '.' && name[2] == '/'); and instead write only return name[0] == '~' || name[0] == '/'; (in SysFileSystem:hasDirectory), i.e., we eliminate the tests for the "./" and "../" cases, then the new tests, test_search_order_4 and test_search_order_5 will pass (they currently don't under 5.0.0). Additionally, *the whole test suite passes.* Tests were made using ./testOORexx.rex -X native_API I will upload the corresponding patch soon. *Some comments more, and some questions* - I get some impression of disorder. Maybe I should have centralized all my submissions in a single place (i.e., in a RFE, for example, or in a bug report)? Currently, it's getting complicated to collect all the information (that's one of the reasons why I am writing that post). In the general case, what's the way to proceed? Should each of the different contributions cross-reference each other? - The patched Unix interpreter passes all the tests, but I don't know whether I've inadvertently introduced some subtle form of new bug. - Patching the Windows interpreter will be much more complicated, and I'm not certain that I possess the required skills to tackle the job. I could try to teach myself C++ (never programmed in C++ in all my life, I started with the DOS PL/I Optimizing Compiler, then learnt machine language and ASSEMBLER for DOS/360 [the "D" version: it had WXTRNs], and then Pascal and REXX for VM/SP -- which spoiled me completely :)) and try to program the required changes, but I'm afraid this would take me several weeks. The real problem, though, is not time (I don't believe we are in a hurry for a new release), but the quality of my hypothetical work. I've noticed that C++ does all kind of weird tricks with pointer arithmetic, and I'm afraid I'd end up by introducing a number of beginner-level bugs if I attempted to solve the problem by myself. Will try it, anyway, if this is what you advise. - What I can produce rapidly (say in one or two days) is a pseudocode version (i.e., a working Rexx program) of what has to be done in the Windows version. Fundamentally, the use of the SearchPath API has to be bypassed, and all checks have to be done "by hand" (like they are being done, already, in the Unix version). Josep Maria Blasco
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
