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
