DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=qE4QvJVyy/BUmBrWBj7N2HulcDBOiATJRQYBT5A5FzNgCHWE/wRgW
	82kTP5nWTKH1mI7aEusY1D+HFO2LVvG1nHlXZ61d5PDQueCJzS2KFL1O1Q1EJXTx
	zwTNQ2p8fv6DgN4Ua6919Wk6+Nqa7ztd6WVeh/rNmra9zqy2cHg5pY=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Thu, 14 Feb 2019 17:20:02 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: textmode for stdout, what is "correct" now?
Message-ID: <20190214162002.GA4950@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <739ed5ce-6902-d702-e152-65dc2c1da667 AT ssi-schaefer DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
In-Reply-To: <739ed5ce-6902-d702-e152-65dc2c1da667@ssi-schaefer.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 14 16:23, Michael Haubenwallner wrote:
> Hi,
>=20
> so I find myself struggling with textmode versus binmode for stdio again.
>=20
> Running the openssl command (from within the apps/ build directory here) =
does
> yield different results regarding carriage return depending on the versio=
n:
>=20
> $ ./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.
>=20
>=20
> $ ./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..
>=20
> Some subsequent shell script does create wrong symlink filenames
> (with embedded CR) when used with openssl-1.1.x.
>=20
> The commit that changed this behaviour in openssl-1.1 is:
> https://github.com/openssl/openssl/commit/bdd58d98467e9f0f6635c1628e1eae3=
04383afb1
>=20
> >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?

> Question now is: These days, what is the correct way to handle this?
>=20
> Is it up to openssl to not use textmode at all with Cygwin (what if
> used from within some cmd.exe?), or is it up to the shell script to
> explicitly drop any carriage return here?

They way openssl does it looks right.  Off the top of my head I don't=20
grok where you get the \r from in the example above.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--5vNYLRcllDrimb99
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxllTIACgkQ9TYGna5E
T6DsnA/+KatgRtLm06xNVAmWeeI0Wk+1COLIA7UFz+xksLf7GOLdrBfKPQy5iWEe
aa801jOf5jSjNN5Slr+aFvWSi3a+1yN8JquyDZQWXwP0gjFBBnVbPfUbyjo4S25G
DA+a76MGubwNnYKIuxdOHim7MUwdX5SHaHe6RyK6Tjtrwu0MM6qHOGpMi397IZ6e
BELwMDMcQW935HScH5qsirLVbJpj1kukP/QKmiSeMTawBY4tAZbq5EVGMzBU58Hx
5Izb0X0Shlk+uDFAqRfZ697sd+Gl13hdVlDdmL4tHXGZqEbSYNVgn1nGeW8Ow3gP
7Nu28704xbeDYP2ZMiygDR3eA0alR4f5XQ3uy9yFFvKpub0slKKxssZZfZEEhnYL
3o97yhv53HQRcf0PpclyFbuexXAoemE2fFBcVbWYyMAd2Zz0pgLC6M+2XPJHl7Rj
qJh6zunKm+HeOsMqb2VTuz52AgJDZXRBF9HN3GbrM7EvwtvBsujl1WnylMLKr2dW
XXjNYjyp8XTwFPvC9hEpCwswjO9QRF1eEoDLbRF70B+67fOA/GYkVQETYYSk7nW8
0CJuXz2eYXttljfQsnHEAcPr9CjmJWVS6vyH2X87fph85jMi5dGre0CVLBFcC+sK
YG8SNu7pjcdlUyJjqL9MZDJ1vvzdCWQ3apcmlI5V24Z0Sg9b/S8=
=ZQU+
-----END PGP SIGNATURE-----

--5vNYLRcllDrimb99--