Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: set -F kills read -t



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.



Messages sorted by: Reverse Date, Date, Thread, Author