On Fri, May 4, 2012 at 3:28 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 May 2012 00:21, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
PipeableOSProcess>>#upToEnd eventually calls AttachableFileStream>>#upToEnd, which tries to perform a buffered read
by
"self nextInto: 1000" (which eventually calls primitiveFileRead which calls sqFileReadIntoAt which calls fread with count arg of 1000).
After further investigation, it seems to me that blocking #upToEnd is functionally the same as #upToEndOfFile, because its test to stop reading data is StandardFileStream>>atEnd, which calls feof(). Therefore, if there is no EOF, it will keep reading until the pipe is out of data, and then hang in fread on the following iteration.
imo stdin upToEnd makes no sense.. one should not expect that data which comes to stdin has any notion of "end", therefore he should never use this method on such stream.
Um, no. See below.
stdin/out are unbound (endless) streams , and use things like eof(), and other of such sort should be discouraged.. since it is same as asking infinity atEnd.
Um, no. One can redirect a file to stdin. One can type EOF to stdin. EOF definitely *does* make sense for stdin. stdin. stdout and stderr are merely well-defined stream names. they can be bound to arbitrary streams, infinite or otherewise. In unix shells piping is built using dup with fork & exec to arrange that some program reads and writes to specific pipe files in a full pipe.
-- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4609991.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- best, Eliot