Another bash-3.2 regression: coloured prompt confuses Ctrl+R.
Hello. The issue was reported at http://bugs.gentoo.org/156292 and is still reproducible in bash-3.2 patch level 10 and with redisplay-cursor-patch. To save you time steps to reproduce the problem: 1. Set PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] ' 2. cd /usr/share 3. press +R, then press letter 'e' and press button. Cursor appears at the first position in the line (the most left column). This is reported to work as it should in bash-3.1 patch level 17. Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -mtune=pentium-m -fomit-frame-pointer -mcpu=pentium-m -pipe uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb 11 19:07:33 MSK 2007 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 10 Release Status: release Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 regression: broken colour prompt
Chet Ramey wrote: > Benno Schulenberg wrote: > > Volkov Peter wrote: > >> In bash-3.2: > >> ~/tmp/bash/bash-3.2 $ mkdir тест/ > > Try the attached patch; it fixes the display problems for me. To add to the chorus: that indeed fixes the cursor problem when having non-ascii in the displayed path. Thanks. Benno ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Another bash-3.2 regression: coloured prompt confuses Ctrl+R.
Volkov Peter wrote: > The issue was reported at http://bugs.gentoo.org/156292 and is > still reproducible in bash-3.2 patch level 10 and with > redisplay-cursor-patch. > > To save you time steps to reproduce the problem: > 1. Set PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] ' > 2. cd /usr/share > 3. press +R, then press letter 'e' and press button. It can also be reproduced with: PS1='\[\e[1;31m\]1234567 X\[\e[0m\] ' The locale must be a utf one: export LC_ALL=en_GB.utf8 The strange thing is: I can't reproduce this on Feisty (the still cooking Ubuntu release), only on Gentoo. Benno ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Another bash-3.2 regression: coloured prompt confuses Ctrl+R.
On Sunday 11 March 2007 21:15:19 Benno Schulenberg wrote: > Volkov Peter wrote: > > The issue was reported at http://bugs.gentoo.org/156292 and is > > still reproducible in bash-3.2 patch level 10 and with > > redisplay-cursor-patch. > > > > To save you time steps to reproduce the problem: > > 1. Set PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] ' > > 2. cd /usr/share > > 3. press +R, then press letter 'e' and press button. > > It can also be reproduced with: > > PS1='\[\e[1;31m\]1234567 X\[\e[0m\] ' > > The locale must be a utf one: > > export LC_ALL=en_GB.utf8 > > The strange thing is: I can't reproduce this on Feisty (the still > cooking Ubuntu release), only on Gentoo. I can confirm the problem here, Ubuntu/Debian might be adding a custom patch for this? -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.2 Official Patch 10
On Fri, 09 Mar 2007 11:39:18 -0500
Chet Ramey <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > On Mon, 5 Mar 2007 17:49:47 -0500
> > Chet Ramey <[EMAIL PROTECTED]> wrote:
> >
> >> Bash-Release: 3.2
> >> Patch-ID: bash32-010
> >
> > I'm still seeing a difference in behaviour:
>
> Yes. That's the difference between the undefined quoting semantics
> in bash-3.1 and the defined semantics in bash-3.2. In bash-3.2, the
> quoting removes all meaning from any characters special to the regular
> expression engine.
>
> >
> > To get the 3.2 results, I expected to have to write:
> >
> > [[ ${v} =~ "\^Alpha" ]] && echo match 4 || echo no match 4
> > [[ ${v} =~ '\^Alpha' ]] && echo match 5 || echo no match 5
>
> Why?
I guess I've gotten into the habit of putting any text string in
double-quotes to avoid having to quote things like spaces, or
single-quotes to avoid having to quote $ as well.
Actually, I didn't expect to _have_ to write it like that, just that it
would be possible; e.g. that the following would be equivalent:
\^Alpha\ Beta
"\^Alpha Beta"
'^Alpha Beta'
(thinking now that perhaps ^ would lose its special meaning in '')
in order to match the literal string `^Alpha Beta' - i.e. without
special meaning to ^.
> The 3.2 behavior means that the match is performed on the
> literal string `\^Alpha', with the backslash and circumflex quoted to
> protect them from interpretation by the regexp matching engine.
> That's the difference.
So effectively, the new rule is that all the regex special characters
lose their special meaning when placed in double or single quotes (much
like '$' does inside single quotes).
Thanks for the clarification.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
