Re: set -F kills read -t

[Bart Schaefer <schaefer@brasslantern.com>]

On Mar 17,  8:10pm, Ray Andrews wrote:
} Subject: set -F kills read -t
}
} func ()
} {
} ...
} read -t input
} echo "$input to a summer's day?"
} ...
} }
} 
} $ echo "Shall I compare thee" | func
} 
} Shall I compare thee to a summer's day?
} 
} ...
} All good. However if 'set -F' is active before 'func' is called  or even 
} it it's set just before the 'read -t input'
} then nothing is readed. Why is that? I thought 'set -F' was just to 
} prevent glob expansions. Can it be fixed?

I'm not able to reproduce this:

zsh -f
torch% func() { set -F; read -t input; print "$input to a summer's day?" }
torch% echo "Shall I compare thee" | func
Shall I compare thee to a summer's day?
torch% 

Also the stuff that you've elided with "..." that comes before "read"
may be important.  When you pipe to a function, the default standard
input of every command in that function is the same as the input of
the function itself, so something else could be consuming the input
before "read" gets a shot at it.

Further, "read -t" means to fail immediately if input is not ready
when "read" begins executing.  Because zsh forks to the left, there
is an inherent race condition in having "read -t" on the right side
of a pipeline; the "echo" in the forked subshell may not yet have
had a chance to do anything by the time that the "read" in the parent
shell examines standard input.

Try examining $? after "read -t input" finishes.  If it's 1, then the
read timed out.

If you change to "read -t 1 input" you may find the problem disappears.