Committed an adjustment.

Using this script :

-- file append.rex

use arg file

call lineout file, "one"

call lineout file, "two"


rexx append.rex read_write.txt
rexx append.rex read_write.txt
cat read_write.txt
one
two
one
two

The same actions with read_only.txt gave
one
twoone
two


Now with the adjusment, I get
one
two
one
two


Jean Louis

2011/11/12 Jean-Louis Faucher <jfaucher.fr@gmail.com>
forget my comment about isopen... It is at the right place in both cases.

The difference between implicit open and explicit open comes from the test isDevice(), done only when explicit open.

Can't tell if this test is needed also in implicit open... I suppose we should have the same behavior in both cases ?

Jean-Louis


2011/11/12 Jean-Louis Faucher <jfaucher.fr@gmail.com>
sorry, I wrote charout[2], this is charout[1].

Jean Louis


2011/11/12 Jean-Louis Faucher <jfaucher.fr@gmail.com>
Still working on the test cases...

From the script below, I see that :
The charout [2] succeeds in implicit opening of the stream, but fails in the ctrl_z stuff.
If the file is empty then the charout [2] succeeds since there is no ctrl_z stuff.
The following char/lineout are ok.

So there is a workaround : use an implicit open and write a dummy line. The following writes will be ok.
 
A last point, I was curious to understand why the first write fails after the command "open", and why it succeeds afer :
In implicitOpen, the attribute isopen is set to true before testing ctrl_z, so not impacted by a write-only file.
In streamOpen, the attribute isopen is set to true after testing ctrl_z, so impacted by a write-only file.

To be consistent, in streamOpen, the attribute isopen should be assigned true before the ctrl_z stuff (in my opinion).
 

file = "write_only.txt" -- permissions : --w--w--w-

say stream(file, "c", "open write append")  -- error 13

say charout(file, "[1]" || "some chars")    -- 13 characters remaining to write (no error if file is empty)

say charout(file, "[2]" || "more chars")    -- 0    correctly written...

say lineout(file, "[3]" || "line1")         -- 0

say lineout(file, "[4]" || "line2")         -- 0

say charout(file, "[5]" || "EOF")           -- 0

say charout(file, "[6]" || "1A"x) -- eof    -- 0




Jean Louis


2011/11/11 CVBruce <cvbruce@gmail.com>
ctrl_z is a hold over from CP/M-80 at least.  CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used.  I don't know why ctrl_z was chosen.  Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice.  I'm sure they had their reasons.

Bruce
On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote:

On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher <jfaucher.fr@gmail.com> wrote:
After replacing the test isDevice() by true, the open is ok, but...
...

Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ?
 
 
Opening a file for write only is supported under Windows.  ctrl_z is a hold over from DOS I think.  I believe I read that the operating system ignores it now and goes by the size of the file.  I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200.
 
I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue.
 
--
Mark Miesfeld
 

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________


------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel