From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-18629-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 22884 invoked by alias); 19 Mar 2014 05:30:39 -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: 18629
Received: (qmail 13884 invoked from network); 19 Mar 2014 05:30:33 -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,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-Injected-Via-Gmane: http://gmane.org/
To: zsh-users@zsh.org
From: Jan Larres <jan@majutsushi.net>
Subject: Re: set -F kills read -t
Date: Wed, 19 Mar 2014 18:30:19 +1300
Message-ID: <lgba0t$aue$1@ger.gmane.org>
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> <lgajta$a1n$1@ger.gmane.org> <532917CD.5060405@eastlink.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: yass.opencloud.co.nz
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <532917CD.5060405@eastlink.ca>

On 19/03/14 17:06, Ray Andrews wrote:
> 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.
>
> 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" *

The best way to do that, and presumably the way grep itself does it, is
to test whether stdin is connected to a terminal:

mygrep() {
    if [ -t 0 ]; then
        echo terminal
    else
        read input
        echo $input input
    fi
}

$ mygrep
terminal
$ echo foo | mygrep
foo input

-Jan