This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: bash: igncr shell option breaks my PS1 prompt
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