From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27568 invoked by alias); 20 Mar 2014 02:16: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: 18640 Received: (qmail 16474 invoked from network); 20 Mar 2014 02:16: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=Xr3DZz19 c=1 sm=1 tr=0 a=ho05/JMXnVToLU2jax5/Hg==:117 a=ho05/JMXnVToLU2jax5/Hg==:17 a=HIA4oEAs-AEA:10 a=8nJEP1OIZ-IA:10 a=8CUJEVAUcs8CJW1gmQ8A:9 a=wPNLvfGTeEIA:10 Message-id: <532A487C.4040906@eastlink.ca> Date: Wed, 19 Mar 2014 18:46:36 -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> <53292481.5090300@eastlink.ca> <140318233741.ZM3708@torch.brasslantern.com> <5329CF1C.5020109@eastlink.ca> <140319152144.ZM4783@torch.brasslantern.com> In-reply-to: <140319152144.ZM4783@torch.brasslantern.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit On 03/19/2014 03:21 PM, Bart Schaefer wrote: > I'm still curious what put you on to "-t" in the first place. I was just Googling for advice on how to get a function to accept piped input and 'read -t' came up several times. Monkey see, monkey do. > Another thing you may be missing here is that "read" consumes ONE LINE > of text: A string ending in "\n" (or end of file). If you do not use > "-t", then it waits as long as it must in order to gobble up one line. > But it won't wait for a second line. Yes, I know that. But it's a place to start. > (Of course you can tell it that something other than a "\n" should be > used as a the line ending, in which case it may very well swallow > everything up to end-of-file on the pipe, but that requires even more > fooling around and -t has you quite well enough confused already.) > > } function y () > } { > } pipeinput='(nothing in the pipe)' > } terminalinput='(nothing from the terminal)' > } if [ ! -t 0 ]; then read pipeinput; fi > } if [ -n "$1" ]; then terminalinput="$@"; fi > } echo "$pipeinput $terminalinput" > } } > > It's a little odd to call $@ the "terminal input" -- you can have stdin > come from a tty device the same as from any other file. All that the > above has said is that you never want to read from a tty, but you're > willing to read exactly one line from anywhere else. Consider: > > $ y 'I met a man with seven wives' <<<'As I was going to St Ives' > > As long as your clams are happy, though ... Now don't go confusin' me again ;-) Hmmm ... no, you're right, it should be able to accept any volume of input as a matter of principal. Ok Bart, how would you write it? The above is a bridgehead in as much as it accepts input from either end, but how could it be improved? I tried 'cat' with no luck. I've already done some chains of pipes (using binaries) up to maybe half a dozen steps, and you just don't have to worry about time-outs, or single lines or anything at all, it just works, even on Tuesday.