bash: igncr shell option breaks my PS1 prompt

bash: igncr shell option breaks my PS1 prompt

[Gene Pavlovsky]

Apparently the latest bash in Cygwin modified the read builtin to use
Cygwin-specific shell option igncr to control ignoring \r characters
in the input (still not clear if that ignores \r\n sequences, or \r
followed by anything else will be also ignored).
This broke a mysql database backup script I had - specfiically reading
output of `show databases` sql command. Since I never used the `igncr`
shell option, with the latest bash update the `read` built-in reads
the database names with \r at the end.
I considered enabling the `igncr` option everywhere, by declaring a
SHELLOPTS=igncr Windows environment variable, however immediately it
created an issue with my two-line PS1 prompt, which contains \n.

# PS1='\e[1;30m\D{%T}\e[m$(test \j -ne 0 && echo "
\e[1;37mj:\j\e[m")${STY:+ \e[1;32m${STY%%.*}\e[m} \e[1;33m\w\e[m\n# '
14:32:22 /usr/local/bin
# set -o igncr
bash: command substitution: line 1: syntax error near unexpected token `)'
bash: command substitution: line 1: `test 0 -ne 0 && echo " j:0")'
14:32:24{STY:+ } /usr/local/bin
# set +o igncr
14:32:26 /usr/local/bin
#

What's wrong with this? It works fine on a Linux box.
I'm considering rolling back bash until I can figure this out.

I really think it was an unwise move to hastily modify the `read` bash
built-in's behavior without a lot of testing. And basically now I
should either put Cygwin-specific checks (if cygwin, then set igncr
shell option) in all of my scripts that *might* be affected, or be
forced to set igncr shell option system-wide, which I'd prefer not to
do.
Can't imagine I'm the only guy whose scripts might be getting weird
problems now. Unless everybody been using `igncr` shell option (off by
default) for ages, and I'm the only guy who just heard about that?
Personally I don't like the `igncr` option's behavior. I want my bash
scripts to fail if somebody saved (or checked out from git) with CRLF
line endings. If it happens, I will notice immediately and then fix
them. Don't want to have bash scripts with CRLF line endings lurking
on my system, pretending to be nice - then one day I'll copy one to my
Linux box where it will break, surprising me more than when I first
created it or checked out from git.

Regards,
--Gene

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Andrey Repin]

Greetings, Gene Pavlovsky!

> # PS1='\e[1;30m\D{%T}\e[m$(test \j -ne 0 && echo "\e[1;37mj:\j\e[m")${STY:+ \e[1;32m${STY%%.*}\e[m} \e[1;33m\w\e[m\n# '
> 14:32:22 /usr/local/bin
> # set -o igncr
> bash: command substitution: line 1: syntax error near unexpected token `)'
> bash: command substitution: line 1: `test 0 -ne 0 && echo " j:0")'
> 14:32:24{STY:+ } /usr/local/bin
> # set +o igncr
> 14:32:26 /usr/local/bin
> #

> What's wrong with this? It works fine on a Linux box.

Try using printf instead of echo, and explicitly quote any dubious characters.

> I'm considering rolling back bash until I can figure this out.

> I really think it was an unwise move to hastily modify the `read` bash
> built-in's behavior without a lot of testing. And basically now I
> should either put Cygwin-specific checks (if cygwin, then set igncr
> shell option) in all of my scripts that *might* be affected, or be
> forced to set igncr shell option system-wide, which I'd prefer not to
> do.

I don't understand, WHY it was modified, if at all.
But did you check the other side of your issue? Does the tool you read from
prints CRLF EOL? And if it is ONLY CRLF, and not CRCRLF, like some silly
things do.

> Can't imagine I'm the only guy whose scripts might be getting weird
> problems now. Unless everybody been using `igncr` shell option (off by
> default) for ages, and I'm the only guy who just heard about that?

Everybody not using CR's for ages to begin with.

> Personally I don't like the `igncr` option's behavior. I want my bash
> scripts to fail if somebody saved (or checked out from git) with CRLF
> line endings. If it happens, I will notice immediately and then fix
> them. Don't want to have bash scripts with CRLF line endings lurking
> on my system, pretending to be nice - then one day I'll copy one to my
> Linux box where it will break, surprising me more than when I first
> created it or checked out from git.

Again, I feel like your analysis is lacking and/or you are mixing things.


-- 
With best regards,
Andrey Repin
Saturday, August 27, 2016 19:16:33

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Gene Pavlovsky]

Re-posting a reply I got from Henri (aka Houder) houder@xs4all.nl
His letter follows:

Hi Gene,

Reread your entry to the mailing list ...

> Apparently the latest bash in Cygwin modified the read builtin to use
> Cygwin-specific shell option igncr to control ignoring \r characters
> in the input (still not clear if that ignores \r\n sequences, or \r
> followed by anything else will be also ignored).


Yes, I have the same problem (Eric is unclear).

As far as I can tell (by experimenting) _all_ \r 's are being removed in
4.3.43 and above (after 'set -o igncr' has been issued).

... 'help set' (on the bash prompt) only refers to line-endings, as far
as I can remember (I am on Linux now).

Eric should clarify ...

------

Apparently the whole affair started with an entry by Mikhail Usenko:

 - https://cygwin.com/ml/cygwin/2015-09/msg00491.html
  - Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2

As far as I can gather, he discovered that a sequence of an odd number
of \r 's before \n were reduced to the same sequence MINUS one (that is
to an even number of \r 's).

(meaning Window line-endings were converted: \r\n -> \n)

... to Mikhail this was a bug ...

Eric reported to have found the problem in the 'read' builtin here:

 - https://cygwin.com/ml/cygwin/2016-08/msg00093.html
  - Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2

(yes, a year later)

Then Eric announced 4.3.43 here:

 - https://cygwin.com/ml/cygwin/2016-08/msg00094.html
  - [ANNOUNCEMENT] Updated: bash-4.3.43-5

A new release of bash, 4.3.43-5, has been uploaded and will soon reach a
mirror near you.  It leaves 4.3.42-4 as the previous version.

NEWS:
=====
This is a minor build that incorporates an upstream bug fix, as well as
disables some old cruft in upstream code that tries to use O_TEXT in the
'read' builtin, but instead ends up eating the character after a
carriage return that is not followed by a newline, even when full binary
operation is desired [1].  With this build, the read builtin now honors
the Cygwin-specific 'igncr' shell option, just like has previously been
done in command substitution and script reading, meaning that you get
binary behavior by default, but enabling 'set -o igncr' makes it
impossible for 'read' to see a carriage return. <====

[1] https://lists.gnu.org/archive/html/bug-bash/2016-03/msg00045.html
...

I had to read this announcement several times before I came up with an
understanding that agreed with the result of my experiment ;-)

(my last e-mail on this issue :-)

Regards,

Henri

On 27 August 2016 at 14:40, Gene Pavlovsky <gene.pavlovsky@gmail.com> wrote:
> Apparently the latest bash in Cygwin modified the read builtin to use
> Cygwin-specific shell option igncr to control ignoring \r characters
> in the input (still not clear if that ignores \r\n sequences, or \r
> followed by anything else will be also ignored).
> This broke a mysql database backup script I had - specfiically reading
> output of `show databases` sql command. Since I never used the `igncr`
> shell option, with the latest bash update the `read` built-in reads
> the database names with \r at the end.
> I considered enabling the `igncr` option everywhere, by declaring a
> SHELLOPTS=igncr Windows environment variable, however immediately it
> created an issue with my two-line PS1 prompt, which contains \n.
>
> # PS1='\e[1;30m\D{%T}\e[m$(test \j -ne 0 && echo "
> \e[1;37mj:\j\e[m")${STY:+ \e[1;32m${STY%%.*}\e[m} \e[1;33m\w\e[m\n# '
> 14:32:22 /usr/local/bin
> # set -o igncr
> bash: command substitution: line 1: syntax error near unexpected token `)'
> bash: command substitution: line 1: `test 0 -ne 0 && echo " j:0")'
> 14:32:24{STY:+ } /usr/local/bin
> # set +o igncr
> 14:32:26 /usr/local/bin
> #
>
> What's wrong with this? It works fine on a Linux box.
> I'm considering rolling back bash until I can figure this out.
>
> I really think it was an unwise move to hastily modify the `read` bash
> built-in's behavior without a lot of testing. And basically now I
> should either put Cygwin-specific checks (if cygwin, then set igncr
> shell option) in all of my scripts that *might* be affected, or be
> forced to set igncr shell option system-wide, which I'd prefer not to
> do.
> Can't imagine I'm the only guy whose scripts might be getting weird
> problems now. Unless everybody been using `igncr` shell option (off by
> default) for ages, and I'm the only guy who just heard about that?
> Personally I don't like the `igncr` option's behavior. I want my bash
> scripts to fail if somebody saved (or checked out from git) with CRLF
> line endings. If it happens, I will notice immediately and then fix
> them. Don't want to have bash scripts with CRLF line endings lurking
> on my system, pretending to be nice - then one day I'll copy one to my
> Linux box where it will break, surprising me more than when I first
> created it or checked out from git.
>
> Regards,
> --Gene

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 2552 bytes --]

On 08/28/2016 03:20 PM, Gene Pavlovsky wrote:
> Re-posting a reply I got from Henri (aka Houder) houder@xs4all.nl
> His letter follows:
> 
> Hi Gene,
> 
> Reread your entry to the mailing list ...
> 
>> Apparently the latest bash in Cygwin modified the read builtin to use
>> Cygwin-specific shell option igncr to control ignoring \r characters
>> in the input (still not clear if that ignores \r\n sequences, or \r
>> followed by anything else will be also ignored).
> 

If the igncr shell option (currently Cygwin-specific, but Chet says that
he is amenable to reviewing it for upstream inclusion in 4.5 once 4.4 is
released any day now) is enabled, then it eats ALL \r, regardless of
context.  In other words, it ignores all carriage returns, as per the name.

>> I considered enabling the `igncr` option everywhere, by declaring a
>> SHELLOPTS=igncr Windows environment variable, however immediately it
>> created an issue with my two-line PS1 prompt, which contains \n.
>>
>> # PS1='\e[1;30m\D{%T}\e[m$(test \j -ne 0 && echo "
>> \e[1;37mj:\j\e[m")${STY:+ \e[1;32m${STY%%.*}\e[m} \e[1;33m\w\e[m\n# '
>> 14:32:22 /usr/local/bin
>> # set -o igncr
>> bash: command substitution: line 1: syntax error near unexpected token `)'
>> bash: command substitution: line 1: `test 0 -ne 0 && echo " j:0")'
>> 14:32:24{STY:+ } /usr/local/bin
>> # set +o igncr
>> 14:32:26 /usr/local/bin
>> #
>>
>> What's wrong with this? It works fine on a Linux box.
>> I'm considering rolling back bash until I can figure this out.

Eating \n is NOT supposed to happen, so it may be that some other bug is
still present in the code.  At least you have given me a test case, so I
can try and reproduce it, and upload a version of bash that does not
have the problem if I can find where the bug actually lives.

But it seems like \n handling in PS1 is independent of any change in
handing in the 'read' builtin.  As evidence, I ran the following test
using the older bash-4.3.42-4 build:

$ bash-4.3.42-4
$ set -o igncr
$ PS1='$(date)\n# '
bash: command substitution: line 1: syntax error near unexpected token ')'
bash: command substitution: line 1: `date)'

$ exit

So you have uncovered a latent problem, unrelated to the recent igncr
fixes, but which is indeed tied to the overall igncr patches, and which
you had no reason to trip over until the igncr change to 'read' changed
your desire to use igncr.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: bash: igncr shell option breaks my PS1 prompt

[Andrey Repin]

Greetings, Eric Blake!

> But it seems like \n handling in PS1 is independent of any change in
> handing in the 'read' builtin.  As evidence, I ran the following test
> using the older bash-4.3.42-4 build:

> $ bash-4.3.42-4
> $ set -o igncr
> $ PS1='$(date)\n# '
> bash: command substitution: line 1: syntax error near unexpected token ')'
> bash: command substitution: line 1: `date)'

That's interesting.

I've just tried it on Linux.

$ PS1='$(date)\n\$ '
Tue Aug 30 06:10:48 MSK 2016
$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

(No idea why they ship this ancient version...)
And on Cygwin

$ PS1='$(date)\n\$ '
Tue Aug 30 06:12:38 MSK 2016
$ bash --version
GNU bash, version 4.3.46(6)-release (x86_64-unknown-cygwin)
$ set -o igncr
-bash: command substitution: line 1: syntax error near unexpected token `)'
-bash: command substitution: line 1: `date)'

> $ exit

> So you have uncovered a latent problem, unrelated to the recent igncr
> fixes, but which is indeed tied to the overall igncr patches, and which
> you had no reason to trip over until the igncr change to 'read' changed
> your desire to use igncr.

Seems like it is related, at least in some way.


-- 
With best regards,
Andrey Repin
Tuesday, August 30, 2016 06:09:31

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: bash: igncr shell option breaks my PS1 prompt

[Nellis, Kenneth]

From: Andrey Repin 
> 
> Greetings, Eric Blake!
> 
> > But it seems like \n handling in PS1 is independent of any change in
> > handing in the 'read' builtin.  As evidence, I ran the following test
> > using the older bash-4.3.42-4 build:
> 
> > $ bash-4.3.42-4
> > $ set -o igncr
> > $ PS1='$(date)\n# '
> > bash: command substitution: line 1: syntax error near unexpected token
> ')'
> > bash: command substitution: line 1: `date)'
> 
> That's interesting.
> 
> I've just tried it on Linux.
> 
> $ PS1='$(date)\n\$ '
> Tue Aug 30 06:10:48 MSK 2016
> $ bash --version
> GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
> 
> (No idea why they ship this ancient version...)
> And on Cygwin
> 
> $ PS1='$(date)\n\$ '
> Tue Aug 30 06:12:38 MSK 2016
> $ bash --version
> GNU bash, version 4.3.46(6)-release (x86_64-unknown-cygwin)
> $ set -o igncr
> -bash: command substitution: line 1: syntax error near unexpected token
> `)'
> -bash: command substitution: line 1: `date)'
> 
> > $ exit
> 
> > So you have uncovered a latent problem, unrelated to the recent igncr
> > fixes, but which is indeed tied to the overall igncr patches, and which
> > you had no reason to trip over until the igncr change to 'read' changed
> > your desire to use igncr.
> 
> Seems like it is related, at least in some way.

But, get this:

$ PS1='$(date)\n\$ '
Tue Aug 30 09:30:37 EDT 2016
$ set -o igncr
-bash: command substitution: line 1: syntax error near unexpected token `)'
-bash: command substitution: line 1: `date)'

$ PS1='`date`\n\$ '
Tue Aug 30 09:31:01 EDT 2016
$

So, the $() syntax is part of the mix. Use back-ticks as a workaround.

--Ken Nellis

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: bash: igncr shell option breaks my PS1 prompt

[Houder]

On 2016-08-30 15:34, Nellis, Kenneth wrote:
[snip]

> But, get this:
> 
> $ PS1='$(date)\n\$ '
> Tue Aug 30 09:30:37 EDT 2016
> $ set -o igncr
> -bash: command substitution: line 1: syntax error near unexpected token 
> `)'
> -bash: command substitution: line 1: `date)'
> 
> $ PS1='`date`\n\$ '
> Tue Aug 30 09:31:01 EDT 2016
> $
> 
> So, the $() syntax is part of the mix. Use back-ticks as a workaround.

Or: replacing \n by \012 also does the trick.

(No! I do not know why!)

Henri :-))

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Houder]

On 2016-08-29 19:43, Eric Blake wrote:
> On 08/28/2016 03:20 PM, Gene Pavlovsky wrote:
>> Re-posting a reply I got from Henri (aka Houder) houder@xs4all.nl
>> His letter follows:
>> 
>> Hi Gene,
>> 
>> Reread your entry to the mailing list ...
>> 
>>> Apparently the latest bash in Cygwin modified the read builtin to use
>>> Cygwin-specific shell option igncr to control ignoring \r characters
>>> in the input (still not clear if that ignores \r\n sequences, or \r
>>> followed by anything else will be also ignored).
>> 
> 
> If the igncr shell option (currently Cygwin-specific, but Chet says 
> that
> he is amenable to reviewing it for upstream inclusion in 4.5 once 4.4 
> is
> released any day now) is enabled, then it eats ALL \r, regardless of
> context.  In other words, it ignores all carriage returns, as per the 
> name.

... uhm ... what about the explanation in the help?

64-@@ bash --version
GNU bash, version 4.3.46(6)-release (x86_64-unknown-cygwin)
...

64-@@ help set
set: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
     Set or unset values of shell options and positional parameters.

     Change the value of shell attributes and positional parameters, or
     display the names and values of shell variables.

     Options:
       ...
       -o option-name
           Set the variable corresponding to option-name:
               ...
               igncr        on cygwin, ignore \r in line endings
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

... this help message should be 'upgraded', should it not?

igncr: removes ALL \r's from value (Cygwin) ?

Henri

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 747 bytes --]

On 08/30/2016 02:49 AM, Houder wrote:
> ... uhm ... what about the explanation in the help?
> 
>       -o option-name
>           Set the variable corresponding to option-name:
>               ...
>               igncr        on cygwin, ignore \r in line endings
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> ... this help message should be 'upgraded', should it not?

Sure, I'll tweak that text, once I can find what about igncr is making
PS1 misbehave on \n.  But help would be welcome, if anyone else is also
interested in looking into the cygwin-specific patches and actually
reviewing them.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: bash: igncr shell option breaks my PS1 prompt

[Houder]

On 2016-08-30 15:40, Eric Blake wrote:
> On 08/30/2016 02:49 AM, Houder wrote:
>> ... uhm ... what about the explanation in the help?
>> 
>>       -o option-name
>>           Set the variable corresponding to option-name:
>>               ...
>>               igncr        on cygwin, ignore \r in line endings
>>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> ... this help message should be 'upgraded', should it not?
> 
> Sure, I'll tweak that text, once I can find what about igncr is making
> PS1 misbehave on \n.  But help would be welcome, if anyone else is also
> interested in looking into the cygwin-specific patches and actually
> reviewing them.

Not only \n ... also on \r:

64-@@ bash --version
GNU bash, version 4.3.46(6)-release (x86_64-unknown-cygwin)
...

64-@@ set -o igncr
64-@@ echo $SHELLOPTS
braceexpand:emacs:hashall:histexpand:history:igncr:ignoreeof:interactive-comments:monitor
64-@@ PS1='$(date)\n# '
bash: command substitution: line 1: syntax error near unexpected token 
`)'
bash: command substitution: line 1: `date)'

# PS1='$(date)\r# '
bash: command substitution: line 1: syntax error near unexpected token 
`)'
bash: command substitution: line 1: `date)'

HOWEVER:

# PS1='$(date)\012# '
Tue Aug 30 19:36:15 CEST 2016
# PS1='$(date)\012\n# '  # <==== \n!
Tue Aug 30 19:36:21 CEST 2016

# PS1='$(date)\012\r# '  # <==== \r!
Tue Aug 30 19:36:26 CEST 2016
#

Perhaps this may help ... in finding the error.

Henri

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Gene Pavlovsky]

Dear Eric Blake,

I understand there were issues with read handling of \r. But is the
resulting solution/bugfix ideal? Or does it introduce new problems?

Basically, I don't want to set `igncr` as system-wide shell option
(e.g. through SHELLOPTS). I want to require scripts to use LF newlines
- if there's a script somewhere with CRLF newlines, I want it to break
immediately (which it would do by default, when igncr is disabled).
Then I will notice and convert it's newlines (dos2unix) right away.
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.

Personally I think that by default read should behave as it did for
years. Backwards compatibility 101... Add a new shell option (separate
from igncr) if you'd like, but keep the default behavior same as it
was for a long time. How do you think?

Regards, Gene Pavlovsky

On 30 August 2016 at 16:40, Eric Blake <eblake@redhat.com> wrote:
> On 08/30/2016 02:49 AM, Houder wrote:
>> ... uhm ... what about the explanation in the help?
>>
>>       -o option-name
>>           Set the variable corresponding to option-name:
>>               ...
>>               igncr        on cygwin, ignore \r in line endings
>>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> ... this help message should be 'upgraded', should it not?
>
> Sure, I'll tweak that text, once I can find what about igncr is making
> PS1 misbehave on \n.  But help would be welcome, if anyone else is also
> interested in looking into the cygwin-specific patches and actually
> reviewing them.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: bash: igncr shell option breaks my PS1 prompt

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1708 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: bash: igncr shell option breaks my PS1 prompt

[Gene Pavlovsky]

On 2 September 2016 at 16:32, Eric Blake <eblake@redhat.com> wrote:
> On 09/02/2016 06:52 AM, Gene Pavlovsky wrote:
>> Dear Eric Blake,
>>
>> 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.

Exactly, so I would really prefer to avoid crutches.

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

The script in question (at the moment) is
[AutoMySQLBackup](https://sourceforge.net/projects/automysqlbackup/).
I didn't make it, I might want to update it when a new version comes
out. Having to add either "set -o igncr" or "| d2u" to the script
creates a maintainability problem - if I ever update it, I should
remember that I did that to this script, and do it again after an
update.
I could make a wrapper for mysql.exe, that pipes it's output through
d2u - which sounds like a bad crutch as well.
Worst thing is, I should spend time investigating why some (other)
script is failing in a non-obvious fashion. Looking through the code
to find out which Windows program it uses that should be piped through
d2u.

No matter how you look it at, the recent change to `read` might have
broken many scripts that were functioning before.
The solution you suggested means broken scripts should first be found,
then investigated, then some Cygwin-specific code added to them. That
sounds like a lot of work, and if the scripts in question are
third-party, a maintainability problem. At the moment, I'm forced to
use an older version of bash due to this particular issue.

Do you see a better solution here?

Regards,
--Gene

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple