On Fri, Oct 4, 2013 at 3:30 PM, Pierre Gaston <pierre.gas...@gmail.com>wrote:
>
>
>
> On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston <pierre.gas...@gmail.com>wrote:
>
>>
>>
>>
>> On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád <
>> arpad.kun...@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
>
In fact, it seems read -t0 is only a select and doesn't read anything
$ echo foo>file;read -t0 var <file ;echo $var #prints nothing
