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

[Dick Dunbar]

> I'm sure that upstream d2u maintainers would
welcome a patch to make it not stall pipelines - but that's a topic for
that list

Or, we could just stay on this list and restore the previous behaviour of
cygwin.
What was so awful about that?   Design decisions that force you to care
are usually not the right ones.  Made for "purity" instead of "usefulness".

The best filter for \r is no filter.

If you want an Opt-In flag to restore previous sed behaviour, I'm  happy to
build a
sed alias to my environment rather than unlearn decades of muscle memory
involved in just getting results.

On Fri, May 12, 2017 at 2:30 PM, Dick Dunbar <address@hidden> wrote:

>
> On Fri, May 12, 2017 at 2:12 PM, Eric Blake <address@hidden> wrote:
>
>> if you are going to be littering your data with \r
>> that should be ignored
>>
>
>
> I'm in the middle of writing another post.   Just want to point out that I
> am
> not the one who is making the decision to "litter" my data with \r.
>
> Way above my pay grade.
>
> Nor do I have any choice over Mac's third option for line-end chars.
> I just have to handle the stuff that is diverted my way  for analysis.
>
> AND I had always depended on cygwin's "least surprise" approach to
> handling this stuff.  The compilers have long ago made peace with the
> end-of-line-wars ... "if you can  figure it out, so can we"
>
> It's just white space.
>
> Good point about the byte-swapping observation in od output.
> I'll have to make an "od" alias to enforce your flags.  I like it.
>
> I posted that because I got really bad results using that example
> on my mintty console.   When the lines are diverted to the screen
> they print a trailing "#" and did not honor the LF to advance to the next
> line.
>
> Perhaps I'll run this again using the 'script' command, even if script
> does
> add ^M at the end of each line.
>
>