From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23007 invoked by alias); 18 Mar 2014 16:22:14 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18619 Received: (qmail 11207 invoked from network); 18 Mar 2014 16:22:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Authority-Analysis: v=2.1 cv=Xr3DZz19 c=1 sm=1 tr=0 a=qpS+1g62PUuaiV1URa5n6A==:117 a=qpS+1g62PUuaiV1URa5n6A==:17 a=HIA4oEAs-AEA:10 a=8nJEP1OIZ-IA:10 a=2bHTXtnYM2Yr01ojoyoA:9 a=wPNLvfGTeEIA:10 Message-id: <532872BE.1020408@eastlink.ca> Date: Tue, 18 Mar 2014 09:22:22 -0700 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-version: 1.0 To: zsh-users@zsh.org Subject: Re: set -F kills read -t References: <20131202142614.GA27697@trustfood.org> <131202075840.ZM3182@torch.brasslantern.com> <140316122727.ZM11132@torch.brasslantern.com> <140316131323.ZM11227@torch.brasslantern.com> <5327B941.3060605@eastlink.ca> <140317235020.ZM30413@torch.brasslantern.com> In-reply-to: <140317235020.ZM30413@torch.brasslantern.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit 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.