From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21495 invoked by alias); 10 Jul 2017 18:43:06 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 21349 invoked by uid 89); 10 Jul 2017 18:43:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Redirection, Redirecting, redirecting, onion X-HELO: mailout12.t-online.de Received: from mailout12.t-online.de (HELO mailout12.t-online.de) (194.25.134.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Jul 2017 18:43:03 +0000 Received: from fwd33.aul.t-online.de (fwd33.aul.t-online.de [172.20.27.144]) by mailout12.t-online.de (Postfix) with SMTP id A8F5F41E96C2 for ; Mon, 10 Jul 2017 20:43:00 +0200 (CEST) Received: from [192.168.2.28] (XdmD-aZUghahHbGpEOczNluf70Epo+3BadO2WCtjiknSKjUgU9H12rx7AR+2GfswDZ@[91.59.12.3]) by fwd33.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1dUde7-0lAiB60; Mon, 10 Jul 2017 20:42:59 +0200 Subject: Re: Redirection to stderr To: cygwin@cygwin.com References: From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= Message-ID: Date: Mon, 10 Jul 2017 18:43:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00145.txt.bz2 Am 10.07.2017 um 14:01 schrieb cygwin-mailinglist: > On Mon, July 10, 2017 12:33, Marco Atzeri wrote: >> Redirecting something on itself it is not guarantee to work. > I'm not sure it is on itself. Are these not two different streams? > > When "some-cmd 2> /dev/stderr" is interpreted by the shell I would expect > that /dev/stderr points to a pipe or terminal *of that shell*. The fd 2 in > "2>", on the other hand, should be the standard error stream *of > some-cmd*. And what did you think that file descriptor of some-cmd would have been without that redirection? I.e. where would some-cmd have got its stderr stream from? The answer is: the shell will pass on a dup()licate of its own stderr channel, which in turn is identical to /dev/stderr. I.e. what that contraption would do, if it worked, would be a no-op. > The redirection plugs the two together. Similar reasoning > applies to the outer layers of the redirection onion. Each process has a > /dev/stderr which stays (or, rather, should stay) valid until that process > ends. Not really. Processes _can_ close their std streams, if they want. -- 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