X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=ZzGAa7+u5fix05WO
	N5aZMrErNgG3x6pfWJn1hWi0k3T4XuYngK4+ekPHdAE7NdY9Sj+WMl+gpqwP1+cy
	ApkVFQtgGFkkdFlGuscne92un7CCmEhW3UPtEQ8dUUuxghYwGXY3vJXVuS/lxhZ4
	Hm7kvGgtOL3dzryCQL1aGF4rNk4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=pPfKynCEMk7iPvsl07Y6N2
	oUy7E=; b=dEM0FL8LZsNSmX7q8sGJYqwzdPSa+wUGk6vtLDQpRGd06D8XlAspdp
	04rTKD6qlNwI1s7yFU48xQRqfjaXSO2PGOtIza9T5/sJf5ATvFMTYojJW3QQp6Ux
	VbaAS+niGSxOBeJNQLlf+uIHqdk7DE7AqHzbmBEUOFZx5SxvRGsFs=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=ham version=3.3.2 spammy=Hx-languages-length:2011, dear, Pipe
X-HELO: mailsrv.cs.umass.edu
Reply-To: moss AT cs DOT umass DOT edu
Subject: Re: Pipe behavior clarification?
References: <CAPJ9Yc9BJXrvrFz3pKQiEzzQ8a8f0_9rPuLn+o+mc5_Zo2wdmg AT mail DOT gmail DOT com> <2e4799d9-e81f-fabb-9f31-3c569a70efc9 AT cs DOT umass DOT edu> <841dff2b-65d9-9d24-2b88-6742f1ea92cb AT redhat DOT com>
To: cygwin AT cygwin DOT com
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID: <e0f341fe-dc2e-8d27-5d04-6e0b3fe91086@cs.umass.edu>
Date: Mon, 23 Jan 2017 09:42:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <841dff2b-65d9-9d24-2b88-6742f1ea92cb@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

On 1/23/2017 9:32 AM, Eric Blake wrote:
> On 01/22/2017 04:23 PM, Eliot Moss wrote:
>> On 1/22/2017 3:19 PM, David Balažic wrote:
>>> Hi!
>>>
>>> Is this a correct pipe behavior?
>>>
>>> $ echo booo | tee >(md5sum --tag) >/dev/null
>>> MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d
>>>
>>> $ echo booo | tee >(md5sum --tag) | cat >/dev/null
>>
>> Here's what I think happens, even if it is a bit counter-intuitive:
>>
>>> (...) creates a subprocess, whose input comes from some kind
>> of pipe or socket, and tee is presented with a filename it can
>> use to write to that socket.
>>
>> The *output* of the >(...) subprocess is hooked up to what is
>> known to be the output of tee *at the time the subprocess is
>> created*.  This happens *before* any > redirections are done.
>
> Rather, all >() and > redirections are performed in left-to-right order.
>  But you are correct that the second >/dev/null is overwriting the
> stdout that was originally given by >(md5sum), and therefore tee is NOT
> writing to the md5sum process.
>
>>
>> However, in the case of the | pipe, that plumbing is set up
>> *before* the >(...) construct is acted on.
>
> Also correct. Mixing >() and | is usually not what you want, as you are
> no longer writing to the pipeline.
>
>>
>> Note that you could do >(md5sum --tag >whatever) if you want
>> to specifically control the output of md5sum.
>>
>> I am sure someone more knowledgeable will correct me if I've
>> missed anything important here :-) ...
>
> You got the gist of it.  Order matters, and specifying more than one
> stdout (by any mix of >, >(), or |) is generally not what you want.

Dear Eric (et al.) -- I *mostly* agree with this, with the exception
that >(...) is *not* an output redirection.  It will present tee with
the name of a file -- either a named pipe or a /dev/fdnnn file name.
By experimentation I discovered that this particular replacement
is not done in the same left-to-right pass as I/O redirections ...

Regards - EM

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple