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

[Dick Dunbar]

Here's another disconnect from that sed change.

- vi t.out
  A --- go to end of line

So if vi can find the end of line, why can't sed?
This is really incompatible and drives experienced developers crazy.

Your comment that $fn was a string and contained no end-of-line chars.

And yet, sed did the right thing here and found the end of ascii text.

It is that kind of experimentation that shows sed is not doing the right
thing.

So a little change like that in order to make linux people feel better
is the wrong place to put a fix to make them compatible.

sed $ should eat \r, \n or end of all ascii text ... on both platforms.

My development experience ranges over AIX, Solaris,  HPUX, Linux in various
distros, Win

I once sat at a cygwin terminal session and wondered why an AIX
command wasn't found.  Scratch-head, Check $PATH, etc.

So the astonishing thing to me at the time was that cygwin had done such
a good job of masking differences among unix-variants and Windows that
I completely forgot I was on cygwin.

This is  a good thing.


On Thu, May 11, 2017 at 12:54 PM, Eric Blake <address@hidden> wrote:

> 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
>
>