colored bash prompts seem to confuse readline
Well ok its not just a plain colored prompt, what I would like to use is this: txtred='\e[0;31m' # Red bldgrn='\e[1;32m' # Green txtrst='\e[0m'# Text Reset PROMPT_COMMAND=' \ if [ $? -eq 0 ]; then \ PROMPT_PREFIX="$txtred"; \ else \ PROMPT_PREFIX="$bldgrn$? "; \ fi ' PS1='$(echo -ne "$PROMPT_PREFIX")'"\$\[$txtrst\] " This is basically taken from http://wiki.archlinux.org/index.php/Color_Bash_Prompt and the version there seems to have the same problems. This is worthwhile craziness I think as it makes the normal prompt unobtrusive and the commands and output easy to see, while still making prompt lines easily distinguishable in the scrollback. And commands that error are easily seeable. And when using wild weird grammar you don't have to continually type '|| echo yip' to everything to see if it works. And it uses green for 'fail' and red for 'succeed' in keeping with the shell's zero-is-true approach to life. But unfortunately it somehow causes readline to get confused, I think. When doing things like up arrow or reverse search part of some old commands seem to get stuck as a prefix in what is displayed, though the command works find when found. Also, multiline commands don't seem to work right (it wraps back over the same line). Britton
Re: colored bash prompts seem to confuse readline
On Tue, Feb 09, 2010 at 08:39:49AM -0900, Britton Kerin wrote:
> Well ok its not just a plain colored prompt, what I would like to use is
> this:
>
> txtred='\e[0;31m' # Red
> bldgrn='\e[1;32m' # Green
> txtrst='\e[0m'# Text Reset
> PROMPT_COMMAND=' \
> if [ $? -eq 0 ]; then \
> PROMPT_PREFIX="$txtred"; \
> else \
> PROMPT_PREFIX="$bldgrn$? "; \
> fi '
>
> PS1='$(echo -ne "$PROMPT_PREFIX")'"\$\[$txtrst\] "
Mixing PROMPT_COMMAND and PS1 is usually a bad idea. You can do this
using PS1 alone. Remember that all non-printing bytes must be enclosed
in literal \[ \] pairs.
red=$(tput setaf 1)
green=$(tput setaf 2)
reset=$(tput sgr0)
color=("$red" "$green")
PS1='\[${color[$?==0]}\...@\h:\w\$\[$reset\] '
(A bit confusing, using C-like evaluation where true is 1 and false is 0,
which is the opposite of bash... hence red being mapped to color[0]
instead of color[1]. But I hope you can understand it without further
explanation.)
Re: colored bash prompts seem to confuse readline
> Well ok its not just a plain colored prompt, what I would like to use is > this: > > txtred='\e[0;31m' # Red > bldgrn='\e[1;32m' # Green > txtrst='\e[0m'# Text Reset > PROMPT_COMMAND=' \ > if [ $? -eq 0 ]; then \ > PROMPT_PREFIX="$txtred"; \ > else \ > PROMPT_PREFIX="$bldgrn$? "; \ > fi ' > > PS1='$(echo -ne "$PROMPT_PREFIX")'"\$\[$txtrst\] " All non-printing character sequences must be enclosed in \[...\]. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
[^/]+ vs. [^/]* - Regular Expression bug?
Hello,
Ran into some particular behaviour with REs in bash, I just cannot
understand how this could possibly be correct behaviour. Then again, I
am no bash guru, could very well be me missing a clue.
If I am wasting your time, sincere apologies.
I am not subscribed to the list, so please include my email explicitly
in any replies that you would like me to read / respond to.
Thanks a million for a great shell! Beers are on me next time any of you
are in Zurich.
Here's the bashbug description:
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include
-I../bash/lib -g -O2 -Wall
uname output: Linux sony2 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28
01:26:53 UTC 2010 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
Two regular expressions should match the same thing, but for some reason
do not:
[[ '/home/' =~ [^/]+ ]]; echo ${bash_remat...@]}
and
[[ '/home/' =~ [^/]* ]]; echo ${bash_remat...@]}
the first matches 'home', the second matches nothing. The only
difference is * vs. + AFAICT, both expressions should match 'home'.
Repeat-By:
Simply evaluate the two lines from the description.
Thanks again,
Morten
Re: [^/]+ vs. [^/]* - Regular Expression bug?
Morten Lauritsen Khodabocus writes:
> Two regular expressions should match the same thing, but for some reason
> do not:
> [[ '/home/' =~ [^/]+ ]]; echo ${bash_remat...@]}
> and
> [[ '/home/' =~ [^/]* ]]; echo ${bash_remat...@]}
> the first matches 'home', the second matches nothing. The only difference
> is * vs. + AFAICT, both expressions should match 'home'.
"[^/]*" matches the null string at the start of '/home/', and there is
no reason for the matcher to try another match.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: + vs. [^/]* - Regular Expression bug?
On Feb 8, 11:38 pm, Morten Lauritsen Khodabocus
wrote:
> Hello,
>
> Ran into some particular behaviour with REs in bash, I just cannot
> understand how this could possibly be correct behaviour. Then again, I
> am no bash guru, could very well be me missing a clue.
>
> If I am wasting your time, sincere apologies.
>
> I am not subscribed to the list, so please include my email explicitly
> in any replies that you would like me to read / respond to.
>
> Thanks a million for a great shell! Beers are on me next time any of you
> are in Zurich.
>
> Here's the bashbug description:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include
> -I../bash/lib -g -O2 -Wall
> uname output: Linux sony2 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28
> 01:26:53 UTC 2010 i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
> Two regular expressions should match the same thing, but for some reason
> do not:
> [[ '/home/' =~ [^/]+ ]]; echo ${bash_remat...@]}
> and
> [[ '/home/' =~ [^/]* ]]; echo ${bash_remat...@]}
> the first matches 'home', the second matches nothing. The only
> difference is * vs. + AFAICT, both expressions should match 'home'.
>
> Repeat-By:
> Simply evaluate the two lines from the description.
>
> Thanks again,
> Morten
* means zero or more characters. It found zero and stopped. You could
do:
[[ '/home/' =~ /([^/]*) ]]; echo ${BASH_REMATCH[1]}
