From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16943 invoked by alias); 19 Mar 2014 04:06:31 -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: 18627 Received: (qmail 8856 invoked from network); 19 Mar 2014 04:06:24 -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=HYUtEE08 c=1 sm=1 tr=0 a=qpS+1g62PUuaiV1URa5n6A==:117 a=qpS+1g62PUuaiV1URa5n6A==:17 a=HIA4oEAs-AEA:10 a=8nJEP1OIZ-IA:10 a=zjBQyNqcoScK_Rcpgx8A:9 a=wPNLvfGTeEIA:10 Message-id: <532917CD.5060405@eastlink.ca> Date: Tue, 18 Mar 2014 21:06:37 -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> <532872BE.1020408@eastlink.ca> <140318104505.ZM15560@torch.brasslantern.com> <5328C3D8.9020603@eastlink.ca> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit On 03/18/2014 04:12 PM, Jan Larres wrote: > On 19/03/14 11:08, Ray Andrews wrote: > As Peter said this is just normal non-blocking I/O, which is not at > all shell-specific let alone zsh-specific. Since you clearly seem to > want blocking I/O, why are you using the '-t' argument to begin with? > If you just wrote 'read input' it should do exactly what you want. -Jan Only because sometimes the input to the function is via arguments, not via pipe. I'm trying to emulate what (say) grep does: ls *.txt | grep some_file vs. grep "grep" * ... and only the '-t' switch seems to work with both forms. Really 'read -t 1' seems perfectly functional, I just wonder about the arbitrariness of a time limit vs. a more robust situation, since in a pipe it seems to me that there is no doubt that input is expected. One should be able to insure that the flow of the code is what one would expect without a 'dumb' pause, I'd say.