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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type:content-transfer-encoding;
	q=dns; s=default; b=DvPm57pYd42eDML2kYhEzdjmnIsbeGdr6MyzoV3IMoy
	Ah8kOtk1UkHAoKLUSyzH+g4r7Of0TBoxmZ34tDR5gXuR0oUGezV1idFtjOP+nOTF
	gvXGThaPJVq9M4SeSLyeG9/rwZ5J53v9JPvd/+HmUYzfyq3Ngt9+VhQ0DWCx7bWc
	=
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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type:content-transfer-encoding;
	s=default; bh=7DhRNefB4RnkLS4nPJ9L3wDV3/s=; b=TNNTcwL9orqpC1Fg/
	c+CLOGZco1PK4f4eQdOo5B/ruGRLLhxlP8fmCNQ8UCwGv65OX3i2p4bnDhjPeHEP
	faAeKsMraf4x/aQcMrkv3xN1aGSZ8j2XGtHAD5cp00A9mbf/sua0fj+BWvVyNjUP
	vqajb/2VwNkXwve0AHFzxXITKQ=
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=0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=Hx-languages-length:1490
X-HELO:	mail-oi0-f53.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=90bNZE2hl3XmSFYVLjY9Dg8/Ci+j90PQmIw+Fgd2Pjc=; b=teM3tKHlmJNPar/m/HTXQWCcjkR4285x/1TYE+6bjwNYlYrTMiBFqXTcjkvmtuC/pV Ksh5e0E67S4dl/Jz6Rf2/kHOjt65cEAbUEUTGhOtgzU8oQ56zJcBxHraRmPv8ip3Syxx Au0lVOdOfvVni+Cgy0KLkrT2owCQhA4FvY/Tk8wd+MgsTKRa8fA6i4Rn3zD3W4jGrhkl N0NIERvUsamYyjCnVX6cPUg6pvgkHfMb6Jt0pHWpZi+QIirGeW6P4k24vvyqv5lfLJf6 noQGdWa5/VtTuyAHlWv++Ek9GIIAaDYOYe0fSX5nihKnESPkyYBOlHoH5porwIyaluJh 9HFA==
X-Gm-Message-State:	AIkVDXIVENIQcEXw9mu5y+k1lyI8lnwIkM0bsi4S4xvgW5sBiLMfp/DrWaidDG+7qoFq8ZBPLkiMbi5odGIZyw==
X-Received:	by 10.202.231.68 with SMTP id e65mr14081624oih.102.1485193070326; Mon, 23 Jan 2017 09:37:50 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<841dff2b-65d9-9d24-2b88-6742f1ea92cb@redhat.com>
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>
From:	=?UTF-8?Q?David_Bala=C5=BEic?= <xerces9 AT gmail DOT com>
Date:	Mon, 23 Jan 2017 18:37:49 +0100
Message-ID:	<CAPJ9Yc-qX-kuwN4K7Jd9WYpotuu791+RO3FxxdQmiXiDXquDoA@mail.gmail.com>
Subject:	Re: Pipe behavior clarification?
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id v0NHc6nF023906

On 23 January 2017 at 15:32, Eric Blake <eblake AT redhat DOT com> 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.

The last part is incorrect. tee is always writing to the md5sum process.
It can be verified by redirecting the md5sum output to a file, like
>(md5sum > file1),
or redirecting the final output to a file instead of /dev/null. In
both cases the (correct)
md5 hash will be there.

Regards,
David

PS: I verified on SLES 11 that the behavior is the same as in cygwin,
so the thread is "technically closed".

--
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

- Raw text -