Re: set -F kills read -t

[Jan Larres <jan@majutsushi.net>]

On 19/03/14 11:08, Ray Andrews wrote:
> On 03/18/2014 10:45 AM, Bart Schaefer wrote:
>> Not always true.  The point of the -t option is to tell "read" that it
>> is in fact more important not to wait than it is to be predictable.
>
> Ok, but in the context of a pipe can't we have 'wait for the input
> that IS coming. Don't wait one second or ten seconds or no seconds,
> wait until the input arrives. Wait until the first 'echo' has done its
> thing. Ain't that intuitive? When would one ever want 'read -t' to
> maybe capture input or maybe not, depending on something
> unpredictable?
>
> echo "a string" | func
>
> should send "a string" to func absolutely every time. The very
> existence of the pipe symbol should say 'wait for it'. Wait for 'echo'
> to return.

As Peter said this is just normal non-blocking I/O, which is not at all
shell-specific let alone zsh-specific. Since you clearly seem to want
blocking I/O, why are you using the '-t' argument to begin with? If you
just wrote 'read input' it should do exactly what you want.

-Jan