From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3770 invoked by alias); 18 Mar 2014 16:58:01 -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: 18620 Received: (qmail 26569 invoked from network); 18 Mar 2014 16:57:48 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f796d000005a13-8a-532878ac05f5 Date: Tue, 18 Mar 2014 16:47:39 +0000 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: set -F kills read -t Message-id: <20140318164739.5a2372d5@pwslap01u.europe.root.pri> In-reply-to: <532872BE.1020408@eastlink.ca> 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> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4Zd01FRrBBsf2aFnsOLmS0YHRY9XB D0wBjFFcNimpOZllqUX6dglcGSsb57MUdPNU7Fyxlb2B8TxnFyMnh4SAicSFw3uZIWwxiQv3 1rN1MXJxCAksZZRY1faFBcphkli/+xYjSBWLgKpEz75jTCA2m4ChxNRNs8HiIgKiEstXbGYH sYUFFCWmrX/LCmLzCthLHPq5DqiGg4NTQFviwd0ykLCQwCMmiScX5EBsfgF9iat/PzFBHGEv MfPKGUaIVkGJH5PvsYDYzAJaEpu3NbFC2PISm9e8ZZ7AKDALSdksJGWzkJQtYGRexSiaWppc UJyUnmuoV5yYW1yal66XnJ+7iRESgl92MC4+ZnWIUYCDUYmHVzJWI1iINbGsuDL3EKMEB7OS CO9qd6AQb0piZVVqUX58UWlOavEhRiYOTqkGxmo234SfOpYf56asEjlr1C6zS+/ek8J4/qPr b8vyFZk/X797nyTH1fNr/0e9DtpoO7/67rIv9kXP78Vd2JYqWefkJc3Df2LW667Nd5g3rN0/ vylt1o4pM71mTMlaW7W/Qd95K0Nc/kOR9XtSRFa0lUlkLesX03y+W0h3bSSvj6Tt90eva+v+ H1diKc5INNRiLipOBACqO1uiHwIAAA== On Tue, 18 Mar 2014 09:22:22 -0700 Ray Andrews wrote: > I have no idea how this 'race > condition' stuff > works but surely, whatever "read -t 1" has that "read -t" lacks should > be automatic? No, that's the whole point of the difference! "read -t" says "test the input state *right now*. Trust me, I really do mean 'right now'. I am over 18". "read -t 1" says "wait at most second to see if some input turns up". When you start a pipeline, do-stuff-with-some-output | do-stuff-with-some-input it's inevitable that what happens on the left and the right is going to take some time. The two processes are asynchronous by design. The only thing the shell guarantees you is that the pipeline itself will be set up (there is some internal synchronisation to ensure there's something running on the left and something running on the right). When input and output are taking place on the processes on the left and right are down to details of those processes that the shell framework for pipelines simply can't worry about. So to ensure synchronisation of input and output you need to do extra work. The "wait a second" option is the easiest way of doing that, although it's not a guarantee. However, there may be better ways, e.g. you can also tell it "read 1 character, waiting until that arrives". It depends what you're ultimate object is. Welcome to "non-blocking I/O"; you've now been through the first lesson, "don't use non-blocking I/O unless you need to". pws