Re: textmode for stdout, what is "correct" now?
On 2/15/19 1:48 PM, Corinna Vinschen wrote:
> On Feb 15 13:03, Michael Haubenwallner wrote:
>> 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:
>>>> 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.
To me it sounds strange to use the one but not the other:
If we don't want O_TEXT at all, isn't O_BINARY obsolete as well,
so the advise should be to use neither - just like real *nix?
A consequence then might be to deprecate (or even remove) them
from the public API header files.
>> Is this correct even for situations where the cygwin1.dll is used
>> outside the Cygwin distribution, like git-bash, MSYS or similar,
> This is OpenSSL, not the Cygwin DLL.
Actually I meant executables linked against the Cygwin DLL being
executed by non-Cygwin (native Win32) programs.
>> where cygwin-based executables eventually are used from within some
>> CMD or PowerShell script? Or should they use unix2dos/dos2unix then?
> Only if the \r is really required. Typically it isn't.
>> OTOH, would it make sense to ignore the O_TEXT flag in cygwin1.dll?
> That's an interesting idea. The O_TEXT flag is already ignored in a lot
> of cases, e.g. for pipes. Only when opening files does it have an
> effect, mostly. I'm not sure we should really switch it off. Maybe we
> can consider a CYGWIN env var setting at one point.
I've thought of the CYGWIN env var too whether to ignore O_TEXT, but the
more I think of it, the more I can think of multiple troubles as well...
>>>> 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...
> I sent a patch upstream and questions got asked. But this is not
> a native openssl lib, this is *Cygwin's* openssl lib, and it should
> behave like a Cygwin lib.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple