From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18765 invoked by alias); 19 Mar 2014 05:00:45 -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: 18628 Received: (qmail 6309 invoked from network); 19 Mar 2014 05:00:38 -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=CJp2XKpz625WaKXmLbsA:9 a=wPNLvfGTeEIA:10 Message-id: <53292481.5090300@eastlink.ca> Date: Tue, 18 Mar 2014 22:00:49 -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> <140318181703.ZM3474@torch.brasslantern.com> In-reply-to: <140318181703.ZM3474@torch.brasslantern.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit On 03/18/2014 06:17 PM, Bart Schaefer wrote: Bart, > Pardon me while I provide further evidence in support of the theorem that > the best way to get the correct answer from the internet is to post the > wrong answer. Who's answer was wrong? > (except of course that the size of the input is not predetermined). If > you cojole that C into a runnable program and try it, you'll find that > it behaves just the way "read -t" does. If you don't want that fcntl() > in there, don't pass the -t option. > Ok, then how else would one write a function that could use arguments *or* piped input? grep does it, and doesn't need an arbitrary wait. Again, in *practice* the " -t 1 " seems perfectly good enough, I don't want to belabour this, it's a theoretical/philosophical point only. > > input=START > if read -t input > then print "I definitely read input: $input" > elif (( $#input )) > then print "Error, input unchanged: $input" > else print "End of file: $input" > fi > Ok, that at least covers the bases if the read failed > } Identical runs of identical code should produce identical results, no? > > No. Consider for example: > > for (( count=1; count <= 10000; count++ )) do > if read -t something > then print "GOT: $something"; break > fi > print $count > done > > This happily counts to 10000, stopping as soon as it gets input. Exactly > how many numbers are printed before it stops depends on when the input > arrives. Identical runs of identical code, but not identical results. > If the most important thing is watching it count, then this is exactly > what "read -t" is for. If the important thing is "GOT: $something", > then don't use -t. Point made. That's well and good, I can see that " -t " would be exactly right in that situation, but in my pipe situation, it's not exactly right. > } Or at least warn you if that isn't going to happen. I appeal to the > } doctrine of least surprise. > > I appeal to the documentation: > > -t [ NUM ] > Test if input is available BEFORE ATTEMPTING TO READ. ... > If no input is available, return status 1 AND DO NOT SET > ANY VARIABLES. Yeah ... I guess in my still synchronous and 'blocking' mind, when there's a pipe there is *always* input so always 'available'. It will take some getting used to the idea that the various steps in a long sequence of piped functions can quit any time they like in any order that happens to happen. > > Consider what would happen if "echo" produced a gigabyte of output, or > a terabyte, or a petabyte. Where is all of that supposed to go while > waiting for echo to return? Do you always expect your web browser to > download an entire video before beginning to play it? A valid point. I have no issue that " -t [seconds to wait] " is available when needed, but in the case of: echo "a string" | func I hardly think that func should not politely wait for "a string", and as my tests showed, sometimes it didn't. I dunno, maybe there is no way that 'read' can be aware that something to the left of it in a pipe situation has returned, so what I'm wanting might be impossible. If it was possible it would be the '-p' switch: 'pipe mode' ... wait for piped input to finish. > } It's just a wrapper function. In this test case, around 'grep'. > > OK, but the wrapper must be doing *something*. I mean, this is a > wrapper around grep: > > mygrep() { > print -u2 "Hi, I'm going to grep now." > grep "$@" > } > > This will perfectly happily read from a pipe, a file, or a file named > in the arguments, without needing "read" at all. So what exactly is > your wrapper doing, such that it needs to consume standard input before > grep does? Yabut, in the pipe situation you don't supply a filespec .... Shoot. All this 'read' stuff has been a colossal mistake. Damn, everything I read on the internet said 'read' was the way to go. HAAA, which get's back to your theorem! I see now how I've been barking up the wrong tree. It never even occurred to me that " $@ " would soak up piped input, I thought " $@ " stuff had to be arguments after the command <:-( Sorry Bart, I'm a long study.