bug#26879: end-of-line issue with cygwin 4.4-1 sed 4.4

[Eric Blake]

On 05/11/2017 02:19 PM, Dick Dunbar wrote:
> Thanks Eric,
> but I'm a bit confused by the response.
> 
> sed is a stream editor;  introducing "binary files" as the reason for a
> change
> that leads to this failure doesn't sound right.

Again, the change you are complaining about is NOT an upstream change,
but a downstream Cygwin change.  Your comments will reach a more
appropriate audience on the Cygwin list.

The cygwin change was made because there are people using cygwin to
process binary files that were surprised that cygwin sed silently ate \r
in those files, where it did NOT do so on Linux.  It was traced back to
sed FORCEFULLY opening files in text mode, even when the user wanted
binary mode.  Silently eating input, with no recourse, is a form of data
corruption.

Yes, when there's a difference between text and binary mode, it's nice
to be able to choose which mode you want to use.  But that's the point -
it should be a choice, not something where the tool says it knows better
than you and forces on you.  If the choice requires you typing a new
command line option, or filtering (whether via d2u or any other viable
filter), at least you are now in full control of your data without sed
presuming whether \r was irrelevant.

Making a change that you can work around (by filtering your data) was
deemed better than leaving the behavior unchanged (where you corrupted
data, and had no viable workaround).

> 
> If I need sed, I'll grab the source to sed and fix it myself.
> Perhaps the busybox version works better, or I should permanently
> switch to the MobaXterm platform instead.

That's one of the beauties of free software - you are ALLOWED to do
that.  In fact, you can take the cygwin sources, and make a one-line
tweak to tell the linker to include textmode.o as part of linking the
final binary, and YOUR build will instantly be back to ALWAYS ignoring
\r on input (and forcefully adding \r on output, even when input did not
have \r).  Or you can indeed use a different pre-built binary if you
don't like the way the cygwin binary behaves.  When it comes to dealing
with the (non-POSIX) difference between text and binary files, there are
several workarounds, some more invasive than others, and not all
downstream ports agree on which method is best.  The Cygwin port has
decided that it prefers Linux emulation (and binary-file preservation)
as a higher priority than windows interoperability; but other projects,
like MSYS, feel differently and go out of their way to maximize
convenience of windows interoperability rather than blind emulation of
Linux.

> 
> Regarding version;  here are the first two lines of sed --version
> $ sed --version
> sed (GNU sed) 4.4
> Packaged by Cygwin (4.4-1)

That doesn't mean that Cygwin's version is 4.4-1, but that your binary
was part of the sed-4.4-1 package from the Cygwin distro.  To learn the
version of cygwin1.dll, you can use 'uname -a', or 'cygcheck -c cygwin'.

> Ok, there is no cygwin 4.4-1 ... but there are hundreds of version
> numbers listed in the components of a cygwin distribution.
> The closest thing I have to a cygwin version is the setup program.

Not to make it more confusing, but cygwin's setup.exe is also versioned
independently from cygwin1.dll.  Some other distros have an overarching
"version" (such as Fedora 25, where I'm typing this email); the Cygwin
project does not choose to use such an overall number.  But even on
distros with an overall number, you still have lots of individual
packages, each with their own independent version number.

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

signature.asc
Description: OpenPGP digital signature