Consider this simple test case entered into test.rexx:
say 1
say 2
say 3
say 4
Then from a command line, type
rexx test > out1.txt
out1 is just as expected, the numbers 1-4, one per line. However, if you take that file and Rexxwrap it:
rexx rexxwrap.cmd
and use just the defaults (no encryption etc.) to get test.exe. Then when you run
test.exe > out2.txt
and run a hex editor on out2.txt, you will see, e.g., "31 0D 0D 0A 32 0D 0D 0A"... !
Somehow the Rexxwrap process adds an extra carriage return ('0d'x) to the output! Moreover, if you edit the original test. rexx file to look like this:
LF = '0a'x
m=charout("stdout", "1")
call linefeed
m=charout("stdout", "2")
call linefeed
m=charout("stdout", "3")
call linefeed
m=charout("stdout", "4")
call linefeed
return
linefeed:
m=charout("stdout", LF)
return
and then you built it into an exe using rexxwrapper, the resulting output file will look like this: "31 0D 0A 32 0D 0A"... ! Vewwwy mysterious.
Finally, I repeated these tests on Linux with the same versions of Regina-rexx and Rexxwrapper. In both cases,
rexx test.rexx > out1.txt
./test > out2.rexx # after building in Rexxwrapper
the output is the same and correct:
310A320A330A340A
Update: I thought I was on to something, working the RXSIOSAY portion of the code - nope. Then I googled the problem and found people suggesting opening stdout as a binary file - again, nope :-(