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
