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:references:from:to:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=ub1FsPqINnAj3nQd
	p8Mgj9z9iGARPXVGAUhDUjBT0MYH0ne5/ijuBTTwt3rTR3FX4WxfVMCpz5Z+adKF
	SP78BizbXUbJp18selidO+HNL/bzm/7OiBDu/sYEXXpGO9tKm+WToNR+VimRwCE9
	1Sw1JFNUg2M3u6zVbk2TPDK5Qks=
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:references:from:to:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=xAA/Ly94mpPodTuIzBbSCg
	grn0A=; b=J0Ygg9dUOIpjUEsn912k0syjUI14/JTCihkpKZsSRrqq71fpJUJS29
	ugGx2ezAmHJSb/qRckT+kg964ssB9WsDeF4EBrAdboQqddDqDcZ2m/J4sddiv7jH
	CKlsw0Jzl7WIwKsv3ehIzzrlaXbTmhBXmMdIZdLyyxmt1dd0341TY=
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-Spam-SWARE-Status:	No, score=0.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=HX-Envelope-From:sk:michael, H*RU:sk:michael, Hx-spam-relays-external:sk:michael
X-HELO:	atfriesa01.ssi-schaefer.com
Subject:	Re: textmode for stdout, what is "correct" now?
References:	<739ed5ce-6902-d702-e152-65dc2c1da667 AT ssi-schaefer DOT com> <20190214162002 DOT GA4950 AT calimero DOT vinschen DOT de> <6aa280c2-4769-0772-91d9-c73a3a3d9680 AT ssi-schaefer DOT com> <20190215102251 DOT GA2702 AT calimero DOT vinschen DOT de>
From:	Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>
To:	cygwin AT cygwin DOT com
Message-ID:	<f7345109-5b22-a342-df1e-940e236c2397@ssi-schaefer.com>
Date:	Fri, 15 Feb 2019 13:03:11 +0100
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version:	1.0
In-Reply-To:	<20190215102251.GA2702@calimero.vinschen.de>

On 2/15/19 11:22 AM, Corinna Vinschen wrote:
> On Feb 15 08:56, Michael Haubenwallner wrote:
>> On 2/14/19 5:20 PM, Corinna Vinschen wrote:
>>> On Feb 14 16:23, Michael Haubenwallner wrote:
>>>> Hi,
>>>>
>>>> so I find myself struggling with textmode versus binmode for stdio again.
>>>>
>>>> Running the openssl command (from within the apps/ build directory here) does
>>>> yield different results regarding carriage return depending on the version:
>>>>
>>>> $ ./apps/openssl version
>>>> OpenSSL 1.0.2p  14 Aug 2018
>>>> $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd
>>>> 00000000: 6139 3464 3039 6535 0a                   a94d09e5.
>>>>
>>>>
>>>> $ ./apps/openssl version
>>>> OpenSSL 1.1.0j  20 Nov 2018
>>>> $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd
>>>> 00000000: 6139 3464 3039 6535 0d0a                 a94d09e5..
>>>>
>>>> Some subsequent shell script does create wrong symlink filenames
>>>> (with embedded CR) when used with openssl-1.1.x.
>>>>
>>>> The commit that changed this behaviour in openssl-1.1 is:
>>>> https://github.com/openssl/openssl/commit/bdd58d98467e9f0f6635c1628e1eae304383afb1
>>>>
>>>> >From an openssl developer's point of view, I can understand to set
>>>> textmode when the intent is to output some text, and to set
>>>> binmode when the intent is to output some binary data.
>>>
>>> How do you create \r\n in this case?  The upstream patch never
>>> adds the explicit 't' flag.  It only adds 'b' or nothing.  So
>>> the output should be \n only unless you write to a file on a
>>> text mode mount.  What am I missing?
>>
>> Down the line in their BIO module they do use setmode(fd, O_TEXT),
>> which is the one that does introduce the \r, as far as I know.
> 
> This one is not so nice.  Somebody should tell upstream we only
> want explicit O_BINARY these days, but no explicit O_TEXT.

Is this correct even for situations where the cygwin1.dll is used
outside the Cygwin distribution, like git-bash, MSYS or similar,
where cygwin-based executables eventually are used from within some
CMD or PowerShell script? Or should they use unix2dos/dos2unix then?

OTOH, would it make sense to ignore the O_TEXT flag in cygwin1.dll?

> 
>> The backtrace in openssl-1.1.1a in this use case is:
>> [...]
>>>> Question now is: These days, what is the correct way to handle this?
> 
> Telling upstream not to use O_TEXT on Cygwin in the first place, I think.

I can do that, but if I were an upstream developer I would ask questions
like above...

> 
> For scripting, d2u should help.

Plus, to be portable: type d2u >/dev/null 2>&1 || d2u() { cat; }

So, firsthand I do prefer to avoid that need.

/haubi/

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