bash: igncr shell option breaks my PS1 prompt
Fri Sep 2 13:32:00 GMT 2016
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
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
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 604 bytes
Desc: OpenPGP digital signature
More information about the Cygwin