X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=LtXpF43
	26m6RsFtS/ddYfTyiiuxGRD8/Xgibgk9e+TxOskaiN8bg7YpExzEB8dJEWqd0Dds
	oCcby6jh7othhcbTNMTDJOSNqLE44/gF65P83mMQAvfjWIrbT0COg5U5X84YuqEM
	X4j8EBHmfW2e9ax6Ds+R+IidVn4MAk9X5+dQ=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=/2eF6Ab/N1m/C
	ahEm5nKk+DrVe0=; b=ef/J312sZKGoQVBMghAC8FkE9RbXPpts+491r3hZ4+qKA
	pee7gGj0c7ZP8TQL7K6EcZlNzmGxst1SDW+/Iolzs3ViAwJW3zW+accTc+Yyw64P
	+a+mw0mMnOaPAqCvubCj1PVoHa8xORp9IyIDx8HgblzEHTAPEGQAqGk6MxnQRA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=His, affair, reduced, gather
X-HELO:	mail-it0-f49.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DrG9Ab3q6sdAonf0iY2U/gKFdmEN8NOk7OyWtR9wV+I=; b=a4EaTTKr1yJKY70oUZt9J8oR6hcWKwdUZAObej7tZLcRBB43rg4Ys9xHA5H3V0jrSr O0Ng73PkFgwx2OZ0CUG7vPoIkk7+XPPkeA8DrbuJ1aoNODgFFlLo3TQ7bbQQn55vSguD IO3M9b6LCzOYdwSnTCiiiaDKgBU/HfAKPaZJJYCXwy3vfPvJh/jNf5cSFWMoimN6xdzS dAUAu/ZN4ODNbiVt0WrO1RZIzM8wPNWIvlBkpzloB7lGJtuaWbfYJpbjTKOyn68QC+f8 817FRv3UIfBjanodY4hrfkWiuk8YaWwoHIm9WgmjOSCFRLP7FXuxXF/q8CxK/kWhHeCN ZuVQ==
X-Gm-Message-State:	AE9vXwO9jCqIk7ivv7nw/mNfGOX/Kc6xRH0WG0cFsB7duOn/BuTFqxRaH/C1m6xMQNkQCMtI9s20jeweeyRyJA==
X-Received:	by 10.36.222.137 with SMTP id d131mr10494216itg.1.1472415603555; Sun, 28 Aug 2016 13:20:03 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<CAPTiy3PE0gZ-hpvQbxVkfaZfxtppDx7RG85WtuigpnL54WZbDA@mail.gmail.com>
References:	<CAPTiy3PE0gZ-hpvQbxVkfaZfxtppDx7RG85WtuigpnL54WZbDA AT mail DOT gmail DOT com>
From:	Gene Pavlovsky <gene DOT pavlovsky AT gmail DOT com>
Date:	Sun, 28 Aug 2016 23:20:03 +0300
Message-ID:	<CAPTiy3N-n5krtWcZuK8-pBQE_efzroS6rizknHqU2tE+BYaMQQ@mail.gmail.com>
Subject:	Re: bash: igncr shell option breaks my PS1 prompt
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

Re-posting a reply I got from Henri (aka Houder) houder AT xs4all DOT 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 DOT pavlovsky AT gmail DOT 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

- Raw text -