Re-posting a reply I got from Henri (aka Houder) hou...@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.pavlov...@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