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
	:content-transfer-encoding; q=dns; s=default; b=N8ZGIrRPjG/2Nomv
	6mfAnJox5xEkprTWST7DYDdRN0P3pLcGPU73WKQDE2U+UxHYw/FguGpd8auKhpMN
	5YMJ8JMlr1rh76Q2UGrG5AhD+qGatLrNQ9CqNpNrER+WFuhIENTf6Shq1UefSpvY
	2OC9Y//vrHtQ8JK08MddsBUBq64=
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
	:content-transfer-encoding; s=default; bh=QqxOAGV9YZsgh1cYZOu55t
	H/TQI=; b=upyCaH6r5lgz27DYnodMJ/Tx4+ud2pV4U5lVhaIU6Hy+qODN8r7+gR
	k1KnHbg6tsp+OVIwYaMSyCFy6jpy0L4qeJhjgxqh87OLp7vBJcbV7LYrlKPaarmi
	tzSmQJB5IdO2AZadSEtBrWiFjHpUTImwch1nPTrtiMUbx5dgvMEuE=
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.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
Subject: Re: Redirection to stderr
To: cygwin AT cygwin DOT com
References: <baa3a4f84968dd6aa9869d2c9f58197f DOT squirrel AT mail DOT schneiderp DOT de> <b4de479d-882e-4e61-2916-1b54f318d76c AT gmail DOT com> <ec89b6011aad4b68a294d3f1d462d40b DOT squirrel AT mail DOT schneiderp DOT de>
From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= <HBBroeker AT t-online DOT de>
Message-ID: <bd1f86ac-bcd4-b1ce-d626-c44662b92deb@t-online.de>
Date: Mon, 10 Jul 2017 20:42:42 +0200
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: <ec89b6011aad4b68a294d3f1d462d40b.squirrel@mail.schneiderp.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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