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