Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#3 windows say/lineout adds extra '0d'x to output

open
nobody
None
5
2009-05-01
2009-05-01
cniggeler
No

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

Discussion

  • cniggeler
    cniggeler
    2009-05-05

    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 :-(