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
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
