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?

> Question now is: These days, what is the correct way to handle this?
> 
> 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 
grok where you get the \r from in the example above.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer