REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014
Microsoft Windows [Version 6.1.7601]
Sample code to reproduce the bug (?) with ooRexx vs. correct or better Regina behaviour:
TST = 'deleteme.tmp' call SysFileDelete TST call lineout TST, 'line 1 of 2' call lineout TST, 'last line' call lineout TST do L = 2 until lines( TST ) = 0 S.L = linein( TST ) end L S.1 = S.2 S.2 = 'inserted line' do L = 1 to L say L S.L call lineout TST, S.L, L end L say 'check' TST exit 0
Regina result (deleteme.tmp, text/plain):
line 1 of 2 inserted line last line
common STDOUT::
1 line 1 of 2 2 inserted line 3 last line check deleteme.tmp
ooRexx result (deleteme.tmp, decoded hex.):
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 6C 69 6E 65 20 31 20 6F 66 20 32 0D 0A 6C 61 73 line 1 of 2..las 00000010 74 20 6C 69 6E 65 0D 0A 00 00 00 00 00 00 00 00 t line.......... 00000020 00 00 00 00 00 69 6E 73 65 72 74 65 64 20 6C 69 .....inserted li 00000030 6E 65 0D 0A 6C 61 73 74 20 6C 69 6E 65 0D 0A ne..last line..
The first written line by ooRexx at the original EOF should be line 1 of 2
(length 11 + 1 EOL),, but somehow ends up as 12 NUL bytes.
The code would work as expected with a call SysFileDelete TST
before the output loop, but I was looking for a solution without any RexxUtil or RegUtil function, because static Regina doesn't have it. In other words, I expected trouble for L = 3
and got it at L = 1
, the manual rexxref/bifLineout.html 7.4.40. LINEOUT (Line Output) mumbles something about...
Note that, unlike CHAROUT, you cannot specify a position beyond the end of the stream for non-binary streams.
Whatever that is supposed to mean, I got no error atL = 3
.
Anonymous
Counted again, 13 NUL bytes matching 11 + CrLf are less bizarre. And the question about Whatever that is supposed to mean wasn't a part of the quoted manual, I just like to know what cannot specify a position beyond the end actually means.
That should be an ordinary open bug report with target 5.0.0 (or next) observed in 4.2.0., please tell me how to fix that.
this means that
call lineout 'ttt', 'x', 100
works as expected (fills in NUL bytes),while
call lineout 'ttt', 'x', 100
doesn't write 99 emtpy lines(this assumes
ttt
dones't exist)Thanks, reading
charout
for your firstlineout
, there is no such thing as a line x + y if x is the last line before EOF and y > 1 outside of a binary RECFM FIXED. However, my case is y = 1:There were 2 lines in the file, and I tried to write line 1, 2, 3. Of course line 1 worked as expected. The new inserted line 2 ended up at a weird place instead of after line 1. After that line 3 worked again as expected, i.e., ending up after the weird line 2.