On 30.12.2025 23:15, Gilbert Barmwater via Oorexx-devel wrote:
Thanks for the heads-up. I've been following the discussion and will incorporate the changes in
my version. BTW, the testcases are almost completed so I should be able to wrap this up shortly.
That is great, thank you, Gil!
---rony
On 12/30/2025 4:49 PM, Rony G. Flatscher wrote:
Gil,
With [r13052], the switch "-og" (global override) got changed to "-od"
(override defaults).
Cf. the discussion at <https://sourceforge.net/p/oorexx/feature-requests/869/>.
---rony
On 15.12.2025 10:20, Rony G. Flatscher wrote:
Gil,
This sounds great!
Could you share your patch so that it can be used for inspection and testing?
---rony
On 14.12.2025 20:15, Gilbert Barmwater via Oorexx-devel wrote:
Hard to believe that I posted this almost two months ago (I've truncated the post after my
first response). Since then, as time permitted, I have been investigating this question by
comparing the prior version of rexx.cpp with the new one, analyzing the differences and
developing tests to demonstrate them. Here is what I found:
1) The prior version recognized both -e (-v) and /e (/v) as well as the upper case versions.
The new version, being based on on the *nix version, only recognizes -e/-v/-o[g] and -E/-V/-O[G].
2) The prior version (using ArgumentParser.h) preserved double quotes in program arguments
while the new version removes them. E.g. rexx myPgm a "b c" d on the command line results in
arg(1) = 'a "b c" d' in the prior version but arg(1) = 'a b c d' in the new version.
Now neither of these behaviors is documented but it is conceivable that existing programs have
been written that make use of them. As there is little reason (IMO) to change them and doing
so could break existing programs, although none have been reported to date, I believe these
should be fixed.
I have also found a bug dating back to the introduction of the .SYSCARGS array. The code has
always handled unknown options/switches (such as -? or -s) by ignoring them and NOT raising an
error. However, the code that sets up .SYSCARGS does NOT account for the presence of (ignored)
options/switches and, as a result, can be wrong, wrongly including command line arguments prior
to the first (the program name for example).
Finally, I was surprised to find that there are NO test cases for the rexx command itself. I
found an empty folder in the testcase directory structure however where such tests would be
located.
Based on the above, I have taken the prior (windows) version of rexx.cpp and 1) removed
redundant and "dead" code with the goal of making the parts that could be the same as the *nix
version match. This fixes the first two items above. 2) Added the code to support the new
"o[g]" option. [Also fixed the problem noted in bug #2041.] Note that this also required a
change to ArgumentParser.h. 3) Fixed the problem with .SYSCARGS so that it correctly reflects
the actual arguments to the rexx program. And finally, 4) replaced the C-style code for
console output and string manipulation with the methods of the C++ classes <iostream> and
<string>. The result has been thoroughly tested successfully.
As I felt it important to have tests for these functions, I took the time to learn how to write
ooRexx test cases. Thanks to Walter's "cookbook" and the (somewhat outdated) documentation in
SVN I got up to speed fairly quickly and have the beginnings of a testgroup for the rexx
command. Before I proceed with fleshing this out, I would like some feedback on what I have
done so far. I propose to commit the testgroup (with the tests that would fail on the current
version of rexx.cpp having been disabled) so that the test case gurus can have a look and
provide feedback. I presume that I don't need to do anything else to get this testgroup to run
when a new build is done but if not, please let me know what else I must do.
Thanks for reading this lengthy post and I look forward to your comments.
Gil B.
On 10/21/2025 12:03 PM, Gilbert Barmwater via Oorexx-devel wrote:
On 10/21/2025 3:38 AM, Rony G. Flatscher wrote:
On 21.10.2025 00:18, dominic wise wrote:
I’m not going to lie – the changes to command line processing for REXX.EXE on Windows make
me somewhat nervous given the number of processes I’ve written over the years that are Rexx
programs called in different scenarios including from batch files. I have found subtle
oddities from time to time but have been able to work around them. If there are any changes
in behaviour to command-line processing I fear that things may stop working due to these changes
Does anyone recall the history of this code and why this difference exists between
Unix(-like) and Windows?
I do not recall the history, it was before my time 🙂. But, in thinking about it, I suspect it
may be related to the Windows support for file/path names containing blanks. The shell
program, CMD.EXE, does some not-so-simple things with the command line when it contains
double-quotes. In some cases they are removed and in other cases they aren't 🙁.--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
