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.