Colored prompt length is not correctly computed - UTF-8
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 turki 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: When retrieving a command from bash's history, emacs keybindings CTRL-E & CTRL-A do not move the cursor to the end and beginning of the retrieved command. CTRL+E moves the cursor to a point that is short of the end of command CTRL+A moves the cursor to a point that is within the bash prompt When the cursor is moved to a location within the prompt, an ensuing CTL+K erases not only the retrieved command, but also the part of the prompt that is to the right of the cursor. This was first noticed on a debian "lenny" system running the default 3.2.39 version of bash running in a color xterm, but was later reproduced on ubuntu 9.04 with bash 3.2.48 in gnome terminal. This was also verified to happen on the linux console - kernel 2.6.26. Repeat-By: $ export PS1="\[\033[0;41m\][$(date +%T)]...@\h:\w]\$\[\033[0m\] " [11:47:48][c...@turki:~]$ echo try as you may CTRL+R may (reverse-i-search)`may': echo try as you may ^ (cursor position) CTRL+E [11:47:48][c...@turki:~]$ echo try as you may ^ (new cursor position) CTRL+A [11:47:48][c...@turki:~]$ echo try as you may ^(cursor now in prompt) CTRL+K [11:47:48][cjns (erases part of prompt) Note, that this does not occur when doing the (reverse-i-search) on "echo", "try", or "as" - it only occurs when searching for "you" or "may". Fix: Not fixes, but either of the following corrects the problem: 1. Removing the escape sequences from the prompt. 2. Switching the locale from UTF-8 (en_US.UTF-8) to ISO-8859-1 (en_US.iso88591).
Colored prompt length is not correctly computed - Correction.
On Sat, Jul 04, 2009 at 12:18:51PM EDT, Chris Jones wrote: > 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 turki 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 > i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release > > Description: > > When retrieving a command from bash's history, emacs keybindings CTRL-E & > CTRL-A > do not move the cursor to the end and beginning of the retrieved command. > > CTRL+E moves the cursor to a point that is short of the end of command > CTRL+A moves the cursor to a point that is within the bash prompt > > When the cursor is moved to a location within the prompt, an ensuing CTL+K > erases not only the retrieved command, but also the part of the prompt that is > to the right of the cursor. > > This was first noticed on a debian "lenny" system running the default 3.2.39 > version of bash running in a color xterm, but was later reproduced on ubuntu > 9.04 with bash 3.2.48 in gnome terminal. > > This was also verified to happen on the linux console - kernel 2.6.26. > > Repeat-By: > > $ export PS1="\[\033[0;41m\][$(date +%T)]...@\h:\w]\$\[\033[0m\] " > > [11:47:48][c...@turki:~]$ echo try as you may > > CTRL+R > may > (reverse-i-search)`may': echo try as you may > ^ (cursor position) > CTRL+E > [11:47:48][c...@turki:~]$ echo try as you may > ^ (new cursor position) > CTRL+A > [11:47:48][c...@turki:~]$ echo try as you may >^(cursor now in prompt) > CTRL+K > [11:47:48][cjns > (erases part of prompt) > > Note, that this does not occur when doing the (reverse-i-search) on "echo", > "try", or "as" - it only occurs when searching for "you" or "may". > > Fix: > > Not fixes, but either of the following corrects the problem: > > 1. Removing the escape sequence¹ from the prompt. > > 2. Switching the locale from UTF-8 (en_US.UTF-8) to ISO-8859-1 > (en_US.iso88591). ¹ To be exact: "removing the color-related escape sequences from the prompt.
Re: Colored prompt length is not correctly computed - UTF-8
Chris Jones wrote: > 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 turki 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 > i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release > > Description: > > When retrieving a command from bash's history, emacs keybindings CTRL-E & > CTRL-A > do not move the cursor to the end and beginning of the retrieved command. > > CTRL+E moves the cursor to a point that is short of the end of command > CTRL+A moves the cursor to a point that is within the bash prompt Thanks for the report. I can reproduce this on bash-3.2.49, and it's fixed in bash-4.0. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Colored prompt length is not correctly computed - UTF-8
On Sat, Jul 04, 2009 at 02:56:20PM EDT, Chet Ramey wrote: [..] > Thanks for the report. I can reproduce this on bash-3.2.49, and it's > fixed in bash-4.0. Thanks for confirming I was not hearing voices or something :-) Is there a 4.0 .deb available..? I just compiled: http://ftp.gnu.org/gnu/bash/bash-4.0.tar.gz This let me verify that the problem is indeed fixed in 4.0 but I'd rather not go the way my of my debian "etch" system, where just about every app I used on a regular basis was from the tarball version. Also, out of curiosity, do you maintain a bug tracking system that can be accessed by the general population? Thanks, CJ
source command differs if in bash or sh mode
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64
-mtune=generic -O2 -pipe
uname output: Linux ws01 2.6.30-ARCH #1 SMP PREEMPT Fri Jun 19 20:44:03
UTC 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
AuthenticAMD GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.0
Patch Level: 24
Release Status: release
Could you CC me please as I'm not on the list. Thanks.
And sorry for bad english...
Description:
If i source a file relative to the current directory then - if
in sh mode - sourcing fails with file not found. If i source a file with
absolute or relative path than it works in sh mode. In bash mode i have
no problem.
/bin/sh is here a symlink to bash.
This behavior is new in version 4, old version 3.2 works fine.
Repeat-By:
cp .bashrc /tmp/bashrc
cd /tmp
create a script like that, make it executable
---
#!/bin/sh
#
CONFIG=$1
echo "CONFIG = "$CONFIG
echo "Test sourcing"
source "${CONFIG}"
echo "Fin"
---
Start it with:
./test.sh bashrc
produces:
CONFIG = bashrc
Test sourcing
./t.sh: line 6: source: bashrc: file not found
Fin
If i change shebang to /bin/bash then it works.
It also works with shebang sh when i specify a explicite path:
$ LANG=C ./test.sh ./bashrc
or
$ LANG=C ./test.sh /tmp/bashrc
Regards
Gerhard
ulimit -p incorrect on linux (and besides being low, probably unenforceable(?))
When under linux (2.6.30.x), I type ulimit -p and get a return value of "8". from the man page this is in 512-byte blocks and may not be set. But if I look into the linux man page: man 7 pipe, under "pipe capacity", I see: In Linux versions before 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 65536 bytes. Of course given standard PC memories for modern systems being measured in Gigabytes, a 64K limit seems ludicrous, but I realize this is an internal (and fixed) internal kernel value on linux. Is there a way to actually read the size of a pipe buffer under linux? A brief look over my linux man pages shows no system call that would allow one to determine the system pipe buffer size, let alone any way to set it. Linda
Re: Colored prompt length is not correctly computed - UTF-8
Chris Jones wrote: > On Sat, Jul 04, 2009 at 02:56:20PM EDT, Chet Ramey wrote: > > [..] > >> Thanks for the report. I can reproduce this on bash-3.2.49, and it's >> fixed in bash-4.0. > > Thanks for confirming I was not hearing voices or something :-) > > Is there a 4.0 .deb available..? I don't know. I don't do Debian packaging, or release binaries at all. > Also, out of curiosity, do you maintain a bug tracking system that can > be accessed by the general population? Sorry, I don't. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ulimit -p incorrect on linux (and besides being low, probably unenforceable(?))
Linda Walsh wrote: > When under linux (2.6.30.x), I type > ulimit -p and get a return value of "8". > > from the man page this is in 512-byte blocks and may not be set. It's set at build time. Look at builtins/ulimit.def:pipesize() and builtins/psize.sh (which uses builtins/psize.c). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: source command differs if in bash or sh mode
Gerhard Brauer wrote: > Bash Version: 4.0 > Patch Level: 24 > Release Status: release > > Could you CC me please as I'm not on the list. Thanks. > And sorry for bad english... > > Description: > If i source a file relative to the current directory then - if > in sh mode - sourcing fails with file not found. If i source a file with > absolute or relative path than it works in sh mode. In bash mode i have > no problem. This is a property of bash posix mode when you don't have `.' in $PATH: 28. The `.' and `source' builtins do not search the current directory for the filename argument if it is not found by searching `PATH'. > This behavior is new in version 4, old version 3.2 works fine. The bash-3.2 behavior was a bug. Its fix is listed in CHANGES: ggg. Fixed a bug that caused a shell running in Posix mode to search $PWD for a file specified as an argument to source/. when the file was not found in $PATH. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Colored prompt length is not correctly computed - UTF-8
Chris Jones wrote: > Is there a 4.0 .deb available..? A bash 4.0 .deb is available in Debian's experimental distribution. I don't know if the dependencies it was compiled with are available in Lenny or Squeeze or not as it would have matched Unstable at one time and so you would need to check. Even if it isn't available (yet) due to the dependencies you could use it as the basis of a backport to Lenny. Bob
