Re: set -F kills read -t

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 03/17/2014 11:50 PM, Bart Schaefer wrote:


Bart:

Confusions within Confuzzlements.
> 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%
Yeah, that works, but your further comments expose what seems to me to 
be a bug.
> 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.

Your code:

  func0() { set -F; read -t input; print "$input to a summer's day?" }

And this run:

  $ s="lowercase s"; S=UPPERCASE S"

  $ echo "$s $S"
  lowercase s UPPERCASE S

  $ echo $S | func0
  UPPERCASE S to a summer's day?

  $ echo $s | func0
  lowercase s to a summer's day?

  $ echo $S | func0
  lowercase s to a summer's day?   << WRONG!

  $ echo "$s $S"
  lowercase s UPPERCASE S

  $ echo $S | func0
  UPPERCASE S to a summer's day?  << THAT'S BETTER

... How can such a thing ever be permitted? That's just plain broken.
But, from your comments I tried this: (it seems the 'set -F' thing is a 
red herring)

  func1() { read -t 1 input; print "$input to a summer's day?" }

... And the same run of tests is fine.  I have no idea how this 'race 
condition' stuff
works but surely, whatever "read -t 1" has that "read -t" lacks should 
be automatic?
When/where would my first run above ever be acceptable? It should print 
the correct
variable, or maybe it should fail completely, but printing the wrong 
variable is just a felony, no?
Nothing is more important than predictability. In a pipe situation, 
'read' shouldn't leave
the station until all the passengers are on board, but even if it does, 
it shouldn't give my
seat to someone else and then call them me.  Or so it looks to this 
grasshopper.