From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5170 invoked by alias); 18 Mar 2014 17:45:22 -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: 18621 Received: (qmail 12333 invoked from network); 18 Mar 2014 17:45:15 -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: <140318104505.ZM15560@torch.brasslantern.com> Date: Tue, 18 Mar 2014 10:45:05 -0700 In-reply-to: <532872BE.1020408@eastlink.ca> Comments: In reply to Ray Andrews "Re: set -F kills read -t" (Mar 18, 9:22am) 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> <532872BE.1020408@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 To add to what PWS just said ... On Mar 18, 9:22am, Ray Andrews wrote: } } ... And the same run of tests is fine. I have no idea how this 'race } condition' stuff works "Race condition" is a term referring to what happens when two (or more) tasks both wish to use the same resource at the same time, but the resource is only available to one task at a time. Think of restroom stalls at a sports stadium at half time; someone ends up waiting, but you can't tell in advance who will get there first. In your case the writer is a janitor arriving to refill the paper towel dispenser, and the reader has just used the sink and need to dry his hands. The -t option tells the reader that if the towel dispenser is empty, he should immediately go away with his hands still wet. If you instead use -t 1, he waits 1 second to give the janitor a chance to do his job. } $ echo $s | func0 } lowercase s to a summer's day? } } $ echo $S | func0 } lowercase s to a summer's day? << WRONG! The "problem" here is that $input is a global variable, so it remained set across runs of func0. In the second case "read -t" failed (if we had bothered to test $? it would have been 1) so nothing new was put into $input and the old value persisted. You could fix this by declaring "local input;" which would cause input to be reset every time the function is called, but that depends on whether you want to be able to refer to $input after the function is finished. (One could argue that "read" should always erase the parameter to which it was told to write, no matter whether the action of reading succeeds; but that's a different conversation.) } Nothing is more important than predictability. Not always true. The point of the -t option is to tell "read" that it is in fact more important not to wait than it is to be predictable. I suspect that what you really want is the answer to the question "is my standard input a pipe?" and to go do something else if it is not. Using "read -t" gives you an unpredictable answer to that question. Without more context of what your function is meant to do when the input is NOT a pipe, we can't tell you the best way to answer that question, or even whether it's the right question in the first place. -- Barton E. Schaefer