From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3424 invoked by alias); 18 Mar 2014 06:50:30 -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: 18617 Received: (qmail 27322 invoked from network); 18 Mar 2014 06:50:23 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140317235020.ZM30413@torch.brasslantern.com> Date: Mon, 17 Mar 2014 23:50:20 -0700 In-reply-to: <5327B941.3060605@eastlink.ca> Comments: In reply to Ray Andrews "set -F kills read -t" (Mar 17, 8:10pm) References: <20131202142614.GA27697@trustfood.org> <131202075840.ZM3182@torch.brasslantern.com> <140316122727.ZM11132@torch.brasslantern.com> <140316131323.ZM11227@torch.brasslantern.com> <5327B941.3060605@eastlink.ca> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: set -F kills read -t MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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.