On 08/09/2017 06:03 AM, Eric Blake wrote:
> On 08/09/2017 03:37 AM, Jannick wrote:
> 
>> Which is a pretty much of a pain when there is no easy fallback solution
>> provided in case a major change is applied.
...
>> This is - to say the least - unpleasant in the light of what Cygwin claims
>> to be, namely 'a large collection of GNU and Open Source tools which provide
>> functionality similar to a Linux distribution on Windows' (from the top of
>> the start website www.cygwin.com).
> 
> On Linux, nothing strips CR automatically.  So on Cygwin, we behave the
> same - nothing strips CR automatically on binary mounted data.
> 
> And the fact that the change was made AND ANNOUNCED back in February,
> but you are now only 6 months later complaining about it, is telling.

It was pointed out to me off-list that my reply can easily be mis-read
in a much more negative tone than I intended, so I'm apologizing for
coming across as mean (yes, I know, https://cygwin.com/acronyms/#WJM).
I think I was trying to emphasize that complaints about the behavior
change at the time of the change were expected (and there was indeed a
reaction, although I was pleasantly surprised at the time that it was
limited to just a few threads, so apparently not many people were
negatively impacted - and that's a good thing).  But complaints about
the behavior after six months are a bit unexpected.  But I guess not
everyone keeps their software up-to-date on quite as frequent a
schedule, so I shouldn't have been as surprised or reacted as harshly.

At any rate, my advice continues to be the same: how would you deal with
CRLF on a Linux system? That's the ideal way to also deal with it on
Cygwin (we used to have gratuitous incompatibilities between the systems
where the same command line on Linux did not have the same result as on
Cygwin; but the change back in February was to get rid of those
incompatibilities, even if it breaks scripts that were unwisely relying
on the incompatibilities).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org