From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-18630-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27936 invoked by alias); 19 Mar 2014 06:38:07 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 18630
Received: (qmail 17728 invoked from network); 19 Mar 2014 06:38:01 -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 <schaefer@brasslantern.com>
Message-id: <140318233741.ZM3708@torch.brasslantern.com>
Date: Tue, 18 Mar 2014 23:37:41 -0700
In-reply-to: <53292481.5090300@eastlink.ca>
Comments: In reply to Ray Andrews <rayandrews@eastlink.ca>
 "Re: set -F kills read -t" (Mar 18, 10:00pm)
References: <20131202142614.GA27697@trustfood.org>
	<131202075840.ZM3182@torch.brasslantern.com>
	<mailbox-21676-1394978698-927113@pepper.0.0.200>
	<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>
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

On Mar 18, 10:00pm, Ray Andrews wrote:
}
} Yeah ... I guess in my still synchronous and 'blocking' mind, when 
} there's a pipe there is *always* input so always 'available'.

Consider this silly example:

    cat /dev/null | func

There will be no output from cat, so as seen by [the commands in the
definition of] func, there's a pipe, but there is no input.

} ... in the case of:
} 
} echo "a string" | func
} 
} I hardly think that func should not politely wait for "a string"

Shell functions are little more than names for the set of commands
inside them; it's nonsensical to say that "func should politely wait".
What will politely wait (or not) is the first command inside func
that attempts to read standard input.  If there is no such command,
nothing waits.

} >    mygrep() {
} >      print -u2 "Hi, I'm going to grep now."
} >      grep "$@"
} >    }
} 
} ... 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 <:-(

It's not actually the case that $@ "soaks up" anything.

   mygrep pattern file

expands to

  {
   print -u2 "Hi, I'm going to grep now."
   grep "pattern" "file"
  }

so grep reads from the file named "file", whereas

   mygrep pattern

expands to

  {
   print -u2 "Hi, I'm going to grep now."
   grep "pattern"
  }

and then grep, noting that it has only a pattern and no file name, reads
from standard input just like it always does.  If there's any magic here
at all, it's that the standard input of mygrep and the standard input of
grep are the same pipe.