Re: read -t 0 anomaly

[Pierre Gaston]

On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston <pierre.gaston@gmail.com>wrote:

>
>
>
> On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád <
> arpad.kunszt@syrius-software.hu> wrote:
>
>> On 2013. October 4. 14:51:00 Pierre Gaston wrote:
>> > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
>> ...
>> >
>> >
>> > There is a race condition, you cannot know if echo will run before read.
>>
>> I see, and it's logical. But this stills confuses me.
>>
>> arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" | { sleep 1s;
>> read -t 0; echo $?; } ; done | sort | uniq -c
>>      10 0
>>
>> I expected that the read will return non-zero in this case. I think it
>> returned with zero because the STDIN was still open. The docs said "read
>> returns success if input is available on the specified file descriptor,
>> failure otherwise". There wasn't any data on the file descriptor, it was
>> just open.
>>
>> Am I still doing something wrong? Or I just misunderstanding the meaning
>> of "input is available" term? I'm not a native English speaker (as you can
>> se from my mails clearly).
>>
>> Thanks,
>>
>> Arpad Kunszt
>>
>>
> Most probably read uses and does what the select() call does.
> In my man select(2) I have:
>
> "more  precisely, to see  if a  read will  not block;  in particular,  a
> file  descriptor is  also  ready  on  end-of-file"
>
> and that's what your exemple does, echo opens stdin and then closes it and
> read sees and end of file.
>
>
>  no worry about your english..
>
>
> ah hmm.....I spoke a bit too fast....read should still not return 0 on end
of file