Web lists-archives.com

Re: textmode for stdout, what is "correct" now?




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