When using the standard coloured prompt in bash-3.2_p5, the shell sometimes gets confused about its cursor position: typing Ctrl+R plus some letter and Home brings the cursor to the leftmost column of the screen. This happens on the console, in Konsole and in xterm. In bash-3.1_p17 it works fine. Using an uncoloured prompt also makes the problem disappear. I can just about always reproduce this by typing Ctrl+R, Shift+D (to recall the habitual 'emerge -Du world -pv' command), and then Home. # echo $PS1 \[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] # locale LANG=en_GB.utf8 LC_CTYPE=en_GB.utf8 LC_NUMERIC=en_GB.utf8 LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=en_GB.utf8 LC_MESSAGES=en_GB.utf8 LC_PAPER=en_GB.utf8 LC_NAME=en_GB.utf8 LC_ADDRESS=en_GB.utf8 LC_TELEPHONE=en_GB.utf8 LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=en_GB.utf8 LC_ALL= # emerge --info Gentoo Base System version 1.12.6 Portage 2.1.1-r2 (hardened/x86/2.6, gcc-hardenednopie, glibc-2.3.6-r5, 2.6.17 i686) ================================================================= System uname: 2.6.17 i686 AMD Athlon(tm) XP 2800+ Last Sync: Sun, 26 Nov 2006 10:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer notitles sandbox sfperms strict test userfetch userpriv usersandbox" LANG="en_GB.utf8" LINGUAS="en en_GB en_US eo es es_ES nl nl_NL" MAKEOPTS="-j1" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_EXTRA_OPTS="--progress --human-readable --exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" USE="3dnow X aac alsa apm arts asf audiofile avi bash-completion berkdb bzip2 cdparanoia cdr cracklib crypt dio dlloader dri elibc_glibc encode exif fam fbcon ffmpeg flac gif glx gphoto2 gpm gtk gtk2 gtkhtml hardened imagemagick imap imlib input_devices_keyboard input_devices_mouse jabber jpeg jpeg2k kde kdeenablefinal kernel_linux lcms linguas_en linguas_en_GB linguas_en_US linguas_eo linguas_es linguas_es_ES linguas_nl linguas_nl_NL lm_sensors mad mbox mbrola memlimit mikmod mime mmap mmx mng modplug mp3 mpeg musepack ncurses nls nptl nsplugin ogg opengl pdf pic png python qt3 quicktime readline recode sasl scanner sdl shorten sndfile sox speex spell sqlite sse ssl svg test theora threads tidy tiff timidity truetype unicode usb userland_GNU userlocales vcd video_cards_fbdev video_cards_vesa video_cards_via vorbis win32codecs wmf x86 xface xine xml xorg xpm xsl xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
bash-3.2_p9 should work
Nope, not fixed. It works fine after doing 'export LC_ALL=C', but not when LC_ALL=en_GB.utf8, for example (both in Konsole and on a VT).
Defining PS1 as follows 'fixes' the problem: PS1='\[\033[001;031m\]\h \[\033[001;034m\]\W \$\[\033[000m\] ' That is: make each number consist of three digits. [[ Observations made before finding the workaround: Using \e instead of \033 makes no difference. Occurrence of the problem (Home going too far left) also depends on the length of the name of the current directory: when this name is longer than three characters, the problem does not occur. So when in root's home dir (~), in /etc or in /usr, hitting Home after a Ctrl+R sequence goes too far left, but when in for example /sbin or /usr/share, it goes to the correct place. When using \w instead of \W, the name of the current dir has to be somewhat longer for the problem to stop occurring: it goes wrong in /etc, /sbin and /buntu, but not any more in /camera and /cdwriter. :| (All this time I'm recalling the command 'emerge -Du world -pv' by typing: <Ctrl+R> <D> <u> <Home>.) ]]
Created attachment 116120 [details, diff] bash-3.2-display-prompt-invis-delete.patch Try attached patch, Chet Ramey suggested to use. It should fix the problem...
Ehm, yes, that is the patch I made myself, Peter. :) It does solve the problem.
Fixed with p17. @Peter: But the problem with multibyte characters in directory names isn't fixed yet. ordesa ~ # mkdir ĉaĉaĉaĉaĉa ordesa ~ # cd ĉaĉaĉaĉaĉa ordesa ĉaĉaĉaĉaĉa # ordesa ĉaĉaĉaĉaĉa # ls somefile ls: cannot access somefile: No such file or directory ordesa ĉaĉaĉaĉaĉa # ordesa ĉaĉaĉaĉaĉa # (reverse-i-search)`': aĉaĉaĉaĉa # saaile(reverse-i-search)`': s': lomes somefile (After twice <Enter>, I've typed there <^R><s><o><m><e>.)
Benno, thank you fro reporting back and closing this bug report. But I did not manage to reproduce any bugs with steps you suggested: peter@camobap ~ $ bash --version GNU bash, version 3.2.17(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. peter@camobap ~ $ bash peter@camobap ~ $ mkdir ĉaĉaĉaĉaĉa peter@camobap ~ $ cd ĉaĉaĉaĉaĉa peter@camobap ~/ĉaĉaĉaĉaĉa $ peter@camobap ~/ĉaĉaĉaĉaĉa $ ls somefile ls: невозможно получить доступ к somefile: Нет такого файла или каталога (reverse-i-search)`some': ls somefile So, please, if you have problems please create new bug report with detailed steps what you did and what went wrong. Assign bug on base-system AT gentoo.org (' AT ' -> @) BTW. You do not need to CC me. I receive all mail from base-system@g.o.
*** Bug 177095 has been marked as a duplicate of this bug. ***
