On 09/02/2016 06:52 AM, Gene Pavlovsky wrote:
> Dear Eric Blake,
> 
> I understand there were issues with read handling of \r. But is the
> resulting solution/bugfix ideal?

Yes.  The recent change to 'read' was a bugfix, and as far as I'm
concerned, it is the ideal fix (you get binary behavior by default, and
text behavior if you use igncr; just as with every other aspect of the
shell controlled by igncr).

> Or does it introduce new problems?

No. The existing problem of igncr vs. PS1 was pre-existing, it was NOT
introduced by the recent change to 'read'.

> 
> Basically, I don't want to set `igncr` as system-wide shell option
> (e.g. through SHELLOPTS).

Don't use it, then.  I highly recommend avoiding 'igncr', because it
exists only as a crutch.  The real solution is to fix your environment
to be binary-clean, at which point you no longer need igncr. But I also
understand that fixing an environment to be binary-clean can be
expensive, so 'igncr' remains as the crutch.

> So, how do I keep an existing bash script, that uses `read` piped from
> the output of a Windows console program that uses CRLF as newlines,
> working, without modifying the script? I don't see how it's possible
> with the current situation.

By piping the output of the Windows program through d2u before handing
it to 'read'.

> 
> Personally I think that by default read should behave as it did for
> years.

Sorry, but I am NOT a fan of default behavior that corrupts my data.  I
am not going to maintain backwards bug compatibility to the broken read
behavior.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org