On Fri, May 4, 2012 at 5:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 May 2012 00:56, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> 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.

what? like putc(EOF)?

No. �One types an EOF character to the shell (see stty) and the shell responds by closing the pipe to the process. �The process then detects an eof condition once it has read all the data from the pipe. �There are no EOF characters in a stream on unix.

but that is a convention between two ends. if another end does not
recognizing EOF character
as an "end of input" signal, it will keep waiting for more data.
since these streams are natually binary, i would be really surprised
if some characters is reserved
for special purposes.

> �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.

right. but as you gave an example, imagine that i used dup()
and one fork keeps writing to stream, while other closes own copy,
do receiving side receives any "EOF" signal? i doubt.

Um, that's not how it is used. �One process (e.g. parent) holds the write end of the pipe and it can close that end. �The other process (e.g. child) holds teh read end and it can detect eof when it consumes all available input.

Here the excert from feof man page:
� �The function feof() tests the end-of-file indicator for the stream
pointed to by stream, returning non-zero if it is set. �The
end-of-file indicator may be cleared by explic-
� � itly calling clearerr(), or as a side-effect of other operations,
e.g. fseek().

which means that actually, eof is nothing else than error which
captured while attempting to read moar from stream, nicely converted
to eof() by higher abstraction level functions (fxxxx C functions).

Right.

�

but if you look at basic infrastructure, supported by kernel (read(),
write()), there is no notion of "eof" for descriptors. all you can
have is an error while attempting to read from or write to descriptor,
and then you can decide how to handle that error by either treating it
as end-of-file or signaling exception etc.

So for files, where eof is an attempt to read beyond end-of-file but not so for pipes and socket streams there is a notion of eof, which is when all data has been read and the write side of the pipe/socketstream is closed. �See pipe(2), &�socketpair(2)

>>
>> > --
>> > 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
>

--
Best regards,
Igor Stasenko.