From: CVBruce <cv...@gm...> - 2010-08-07 21:11:21
|
Hi, I've been playing around with pipes today after the discussion about Chars and Lines returning 0 for transient streams. I wrote a couple of programs to play around with. Here is the first program called Sender.rex #!/usr/bin/rexx Buffer = XRange("0","9")||XRange("A","Z")||XRange("a","z")||"$#" X = LineOut('STDERR','S->'||Stream('STDOUT','State')); Do I = 1 to 5 X = LineOut('STDERR','S-> Sending Buffer'); X = CharOut('STDOUT',Buffer); X = LineOut('STDERR','S-> '||Stream('STDOUT','STATE')); Call SysSleep 10 end; X = Stream('STDOUT','C','CLOSE'); Call SysSleep 10; exit; And the second one called Receiver.rex #!/usr/bin/rexx Count = 0; Say 'R-> '||Stream('STDIN','State') Do forever while (Stream('STDIN','State') = 'READY'); Buffer = Charin('STDIN',,16); Count = Count + Length(Buffer); Say 'R-> '||Count||' '||Stream('STDIN','State');; end; exit The command I used was -> Sender.rex | Receiver.rex So I expected the output of Sender.rex to be something like this: S-> READY S-> Sending Buffer ... S-> Ready I shouldn't be creating any buffer overflows because I'm only sending 64 characters through the pipe at a time and giving 10 seconds for Receiver.rex to receive the characters off of the pipe at the other end. To tell you the truth, I didn't know what to expect for output from Receiver.rex I would expect Chars to return 0 after the first 64 characters were retrieved from the pipe, because there would be no more characters to read. But I wasn't sure what the 'State' would be. I felt fairly sure that when I closed the pipe, it should be a 'NOT READY' This is what happened. As soon as Sender.rex wrote one buffer to the pipe, the state changed to 'ERROR' and stayed there. I tried issuing a 'flush' command in hopes that this would clear it. This didn't stop me from sending more buffers. The state of the pipe in Receiver stayed 'READY' so I entered a blocked read when I hit Charin. When I closed the stream in Sender, the state in Receiver went to 'ERROR', not at all what I was expecting. I can state that all of the data I sent was received, but the metadata about the streams was not at all what one would expect. Bruce |
From: Jean-Louis F. <jfa...@gm...> - 2010-08-08 17:05:53
|
On the reader side, we have the status ERROR at the end because of that : void StreamInfo::readBuffer(char *data, size_t length, size_t &bytesRead) { if (!fileInfo.read(data, length, bytesRead)) { fprintf(stderr, "\n*** StreamInfo::readBuffer\n"); notreadyError(); } ... There is no EOF test here, if fileInfo.read returns false, then it's an error, always. If appropriate (is it ?) we could call checkEof() instead of notreadyError(). Tested under Windows and Unix : with this change, we get NOTREADY:EOF instead of ERROR:0 at the end of execution of receiver.rex On the writer side, under Windows, we don't get the status ERROR, it's always READY Under Unix, we get the status ERROR because of StreamInfo::WriteBuffer which calls fileInfo.getPosition If it does that, it's because stdout is not declared transient... Tested under Windows : stdout is transient Tested under Unix : stdout is not transient So now, must see why stdout is not transient under Unix... |
From: CVBruce <cv...@gm...> - 2010-08-08 18:11:33
|
Ok looks like I made a bad assumption. When the problem was first presented, I said that it wasn't about STDIN, but with transient streams, because this fails cat data.txt | myprogram.rex While this doesn't myprogram.rex <data.txt The only difference I could see was that the pipe makes it a transient stream. I agree on my Mac system the pipe shows up as a persistent stream. This would indicate that should be able to seek to an offset on a pipe. Not something that makes sense to me. Bruce On Aug 8, 2010, at 10:05 AM, Jean-Louis Faucher wrote: > On the reader side, we have the status ERROR at the end because of > that : > void StreamInfo::readBuffer(char *data, size_t length, size_t > &bytesRead) > { > if (!fileInfo.read(data, length, bytesRead)) > { > fprintf(stderr, "\n*** StreamInfo::readBuffer\n"); > notreadyError(); > } > ... > There is no EOF test here, if fileInfo.read returns false, then it's > an error, always. > If appropriate (is it ?) we could call checkEof() instead of > notreadyError(). > Tested under Windows and Unix : with this change, we get > NOTREADY:EOF instead of ERROR:0 at the end of execution of > receiver.rex > > On the writer side, under Windows, we don't get the status ERROR, > it's always READY > Under Unix, we get the status ERROR because of > StreamInfo::WriteBuffer which calls fileInfo.getPosition > If it does that, it's because stdout is not declared transient... > Tested under Windows : stdout is transient > Tested under Unix : stdout is not transient > > So now, must see why stdout is not transient under Unix... > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |