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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=QmaN BhgTf8HK5YYmPvN+z1QVHjpT9UUkRWRcJgKQsfADFBKCXpXtBmyB9NcPBEJBqihk EeN8CYKmbudzvnsLHR5fd/g35XmxqeQtnj2LDScfbJH5HefaNJEjmKZ0pyFKwU4I mS2DmsUfVuqQkM6IRRUqSrIiKX4bnsVXRvsCHbU= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=O3USKBCx1j j9lYaQjezNN+wdLKI=; b=i+YQohAuADBITo0f/EsBlT2vrQRYicq/B9MuUbN3vE D4L/CQ6sVfXT9pOaUIemtZK7kvU7BCfZsLM2VXl/+O0zztsQyQcDva5k/Lb6CBsE xZxtsmha9HmvE3R4Jy3xOrMqKQTbU96vGXPdAj3jy3Qd6djaLxtd198dcmLR78Zx 4= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,UNSUBSCRIBE_BODY autolearn=ham version=3.3.2 spammy=H*i:sk:2e4799d, H*MI:sk:2e4799d, H*f:sk:2e4799d, Pipe X-HELO: mx1.redhat.com Subject: Re: Pipe behavior clarification? To: cygwin AT cygwin DOT com References: <2e4799d9-e81f-fabb-9f31-3c569a70efc9 AT cs DOT umass DOT edu> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: <841dff2b-65d9-9d24-2b88-6742f1ea92cb@redhat.com> Date: Mon, 23 Jan 2017 08:32:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2e4799d9-e81f-fabb-9f31-3c569a70efc9@cs.umass.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="956MA7krNkR8pI4ee5hwG4boxhaSqr6W3" X-IsSubscribed: yes --956MA7krNkR8pI4ee5hwG4boxhaSqr6W3 Content-Type: multipart/mixed; boundary="H13E6tw94we5uuF6tWiEuVsdSerjmiBTD"; protected-headers="v1" From: Eric Blake To: cygwin AT cygwin DOT com Message-ID: <841dff2b-65d9-9d24-2b88-6742f1ea92cb AT redhat DOT com> Subject: Re: Pipe behavior clarification? References: <2e4799d9-e81f-fabb-9f31-3c569a70efc9 AT cs DOT umass DOT edu> In-Reply-To: <2e4799d9-e81f-fabb-9f31-3c569a70efc9 AT cs DOT umass DOT edu> --H13E6tw94we5uuF6tWiEuVsdSerjmiBTD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/22/2017 04:23 PM, Eliot Moss wrote: > On 1/22/2017 3:19 PM, David Bala=C5=BEic wrote: >> Hi! >> >> Is this a correct pipe behavior? >> >> $ echo booo | tee >(md5sum --tag) >/dev/null >> MD5 (-) =3D 9c8b79bdf79ef0ee73a77b8d36d27a2d >> >> $ echo booo | tee >(md5sum --tag) | cat >/dev/null >=20 > Here's what I think happens, even if it is a bit counter-intuitive: >=20 >>(...) 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. >=20 > 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. >=20 > 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. >=20 > Note that you could do >(md5sum --tag >whatever) if you want > to specifically control the output of md5sum. >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --H13E6tw94we5uuF6tWiEuVsdSerjmiBTD-- --956MA7krNkR8pI4ee5hwG4boxhaSqr6W3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYhhQOAAoJEKeha0olJ0Nq2TkH/R+rX6auFcnc9yeBh/35vL05 xcWfknobeX+9ABMNISGJE9q8tIitQ7OrEHYu7vSMPht70VJSc+K4kCHtMxhSg77T c47gVVDi1sjS6mFXpze31rTw9/nZ+k0IPuzvcKjwifso1Rb9o8cNFNrwPmYFS8yw SboYHQre6a5hxqCQi9ABKcIJW9wkIhcI2Wfdi8xNlKsMZefKoDI9MLedHYgOJSEF lYx9W96ywvgi1yf87mAS0LaeCNsmAvIlUjbyGQgqf0zyKxuunXvj2n3ZGaMJjeQn 8dx/+Ri8iroTWZeloxGP//M+BM1fuc57NTntHcOi1K++Ing+5lu2x0Le81bE7NA= =ADmN -----END PGP SIGNATURE----- --956MA7krNkR8pI4ee5hwG4boxhaSqr6W3--