If one types from the bash command line: set -o vi ls<ESC>x then the terminal beeps and the 's' is not erased. In fact, you cannot go into vi control mode at all.
This only happens if you have 'set -o vi' in your .bash_login script. If you don't have this, log in, and then type 'set -o vi' on the command line, then everything works fine. This is a problem with all bash versions on the Redhat 6.0. This was not a problem with all bash versions on previous Redhat distributions.
This bug affects bash version 1 and version 2.
This may be a problem with one if the libraries that bash uses. I pulled down bash-2.03 from prep.ai.mit.edu and compiled it on a Redhat-6.0 installation and a Redhat-5.2 installation. On Redhat-6.0 it did not work and on Redhat-5.2 it worked fine.
*** Bug 2530 has been marked as a duplicate of this bug. *** emacs mode seems to work, but vi mode doesn't work. ------- Additional Comments From ayn2 05/04/99 02:10 ------- This is a duplicate of #2397 ------- Additional Comments From kaboom 05/04/99 09:37 ------- Oops, you're right. Sorry, I missed that one. BTW, the bug is probably in readline, not in bash itself.
Contrary to what lu.edu says, set -o vi doesn't solve problems either
I tried installing a copy of bash-1.14.7-13 from my RedHat 5.2 disk in the RedHat 6.0 system, and it did not solve the problem. Also tried downgrading libtermcap with no luck. I don't know anything else to try... It would be nice to get this solved. Maybe I can clarify something... If you have "set -o vi" in your .bashrc, then you've permanently killed vi emulation for your shell. However, if you remove it from your .bashrc and type "set -o vi" at the command line, the vi emulation works fine. And nope, a "set +o vi" then "set -o vi" does not fix things if you have "set -o vi" in your .bashrc file. It must be initialization code...
*** Bug 3323 has been marked as a duplicate of this bug. *** If you type "set -o vi" to bash then <esc> is supposed to take you to command mode, where you can use normal vi movement commands. It doesnt work on sparc - though works fine on other RH's
*** Bug 2738 has been marked as a duplicate of this bug. *** ~/.inputrc is not processed when bash is spawed via login, new xterm, or exec'ing. so, you don't get to do ful things like: set horizontal-scroll-mode On set bell-style none Control-f: forward-word Control-b: backward-word save my sanity, make this work. ------- Additional Comments From jbj 05/15/99 16:31 ------- *** Bug 2736 has been marked as a duplicate of this bug. *** After upgrading from 5.2 to 6.0 I encountered this very annoying problem. At console, Alt-b is backward word. In an Xterm, it inserts itself. Creating a .inputrc containing set convert-meta On does not cause subsequent xterms to behave properly. nxterm exhibits the same problem. ESC-b behaves properly in all settings. frop:11 $ echo $SHELL /bin/bash frop:12 $ echo $BASH_VERSION 1.14.7(1) frop:13 $ rpm -q bash bash-1.14.7-16 frop:16 $ rpm -q -f /usr/X11R6/bin/xterm XFree86-3.3.3.1-49 ------- Additional Comments From jbj 05/15/99 18:28 ------- *** Bug 2404 has been marked as a duplicate of this bug. *** I just installed RH6.0, upgrading from a 5.2 system, and I am finding that I cannot use the meta key to perform Emacs-style editing operations from within bash or ncftp, both of which use termcap. This worked fine in the latest XFree86 package update released for 5.2, so I assume that something has changed in termcap for 6.0. Oddly enough, I can use the meta key as before when running either rxvt or the GNOME terminal program, which suggests the termcap entry for xterm having changed. However, tcsh gets the meta key stuff right in an xterm window, and it uses termcap directly, without going through readline. Backing out the RH6.0 readline RPM and installing the 5.2 RPM makes no difference, so I doubt readline is the problem. I use the meta keys all the time in both bash and ncftp, so it's very confusing to have them misbehave. ------- Additional Comments From jbj 05/16/99 13:17 ------- *** Bug 2852 has been marked as a duplicate of this bug. *** After doing "set -o vi", vi editing commands don't work with bash anymore. ------- Additional Comments From bischo 05/21/99 10:16 ------- xterm does not format its columns properly using ls anymore -- they don't line up like they should. I don't know if this is the same problem or not, but I suspect that it is all related to the terminal settings somehow. I don't know if this helps, but if I use xterm to rlogin into a RedHat 5.2 system from my 6.0 system, I can use alt/meta fine. I am not familiar with the low-level workings of terminals, but the issue doesn't seem to be with xterm per se, as an rlogin shell on another machine has no problems in a RedHat 6.0 xterm. Also, I downloaded and compiled xterm from XFree86 and had the same problem. Hope this helps. Please fix this - it's driving me crazy! ------- Additional Comments From bischo 05/21/99 10:31 ------- One more thing ... I noticed that a fresh xterm does not have the column-formatting problem *until* you try to use meta-backspace to delete a word. ------- Additional Comments From thoth 05/23/99 01:03 ------- ian.edu tells me that this is caused by 6.0 adding INPUTRC=/etc/inputrc to /etc/profile, which activates the bogus config in /etc/inputrc which has been there since 5.2 . To restore proper function, remove the offending "set convert-meta" from /etc/inputrc. ------- Additional Comments From thoth 05/23/99 11:44 ------- ian.edu tells me that this is caused by 6.0 adding INPUTRC=/etc/inputrc to /etc/profile, which activates the bogus config in /etc/inputrc which has been there since 5.2 . To restore proper function, remove the offending "set convert-meta" from /etc/inputrc. ------- Additional Comments From dale 05/28/99 16:26 ------- *** Bug 2921 has been marked as a duplicate of this bug. *** when I put "set -o vi" into .bashrc, ESC-k and ARROW-UP stops working in the shell. when I type it in manually instead, things work fine. Could it have something to do with readline initialization ? (I have no idea). Thanx, John ------- Additional Comments From dale 05/28/99 16:27 ------- *** Bug 3116 has been marked as a duplicate of this bug. *** After upgrading to redhat-6.0, the user's .inputrc files stopped working. Investigatigation revealed that INPUTRC is set in /etc/profile, pointing to /etc/inputrc. Worse, it assumes everybody want's editing-mode-emacs. Even "Fixing it" by submitting "set -o vi" does not work, because the key bindings in /etc/inputrc break vi-editing-mode. Most people know vi, not emacs. So it is a mystery to me why you want to force emacs mode in bash, and even prevent the bash builtin 'set -o vi' to work. ------- Additional Comments From jturner 06/10/99 10:51 ------- *** Bug 3376 has been marked as a duplicate of this bug. *** When you put "set -o vi" in a .bash_profile in Red Hat 6.0, vi mode doesn't work at all. When you type it in manually, it works fine. This seems like a bug in readline, not a choice of features as Cristian Grafton has suggested. When one adds "set -o vi" to a .bashrc, then vi edit mode never works correctly afterwards. When you type it in manually, you get great results. Once bash processes the "set -o vi" in a .bashrc, no amount changing edit modes manually will make vi edit mode work correctly [emacs edit mode seems unaffected]. It makes the system MUCH more unfriendly to vi users than the old version was to emacs users. Yeah, home and end work, but now nothing else does - at least not for vi users. The workaround is given by David A. DeGraaf on the hedwig-list: I found that the new line in /etc/profile is culpable: INPUTRC=/etc/inputrc When I commented this outbash worked again as it should. I have no idea why this line is there or what function is lost by removing it. It's just one of those little mysteries...
*** Bug 3521 has been marked as a duplicate of this bug. *** Bash vi editing mode cannot be set in .bashrc with "set -o vi" unless the /etc/inputrc file that is installed with RH 6.0 is removed. The /etc/inputrc file installed with RH 6.0 sets parameters for emacs editing mode. I think I could run "set -o vi" from the command line and get it to work, even with the /etc/inputrc file unchanged, but not from .bashrc. Coworkers of mine have complained about the same problem. -- Al Borchers*** Bug 3528 has been marked as a duplicate of this bug. *** When I do a "set -o vi" in my .bashrc, log in and do a "set -o" I get the following: $ set -o braceexpand on noclobber off ignoreeof off interactive-comments on posix off emacs off vi on allexport off errexit off histexpand on monitor on noexec off noglob off nohash off notify off nounset off physical off privileged off verbose off xtrace off Yet my vi command line editing doesn't work.
*** Bug 3702 has been marked as a duplicate of this bug. *** Although the 'set -o vi' option works if typed in at at the prompt, it fails to work if included in .bashrc. Moreover if .bashrc includes the line 'set -o vi' setting option vi by hand has no effect. I suspect this is not actually a problem with bash but with a library call that bash uses. As executables which previously worked fine, fail with the 6.0 distribution. ------- Additional Comments From 06/24/99 09:59 ------- To fix the problem I commented out the line: INPUTRC=/etc/inputrc from /etc/profile and it works fine now.
I wasn't logged in when I made the comment above about commenting out INPUTRC in /etc/profile.
*** Bug 4037 has been marked as a duplicate of this bug. *** I performed an upgrade from 5.1 to 6.0. After upgrade had completed the vi command recall and line editing will not work under bash. However, on another system that I did an install instead of an upgrade the vi command recall and line editing work fine. When you execute the "set -o vi" on both systems it does set the "vi" value to "on" as seen with a "set -o" command. However, on the upgrade system it doesn't work, and on the fresh install system it does. The bash fileset version is the same on both - bash-1.14.7-16. ------- Additional Comments From lanny.t.tavasci 07/30/99 21:50 ------- Additional information: It seems that this problem is related to the /etc/inputrc file that is installed with Red Hat 6.0. The 5.x systems did not have that file. On systems where the vi command line editing does not work for bash when I remove the /etc/inputrc file it fixes the problem. I still don't know why the vi command line editing worked on scratch installed 6.0 systems with the /etc/inputrc file in place and not on the upgraded 5.x systems, though I have found out recently that in some cases it didn't work for any user other than root on a scratch installed 6.0 system. On upgraded 5.x systems it failed to work for all users including root. ------- Additional Comments From timw 08/10/99 19:01 ------- Please dup this bug to 2397. Fix is comment out the assignment to 'INPUTRC' in /etc/profile. The supplied /etc/inputrc is bogus.
This pretty much boils down to whether we care more about people needing 8bit input on the command line or people that do need vi modeline. As it seems that people knowing about vi modeline are more advanced users that can figure out uncommenting the INPUTRC setting in /etc/profile we'll have to stick with the setting that we have now - as there seems to be no way we can have bothnworlds in bash 1.x
*** Bug 14638 has been marked as a duplicate of this bug. ***
I just thought I'd mention that section F6 of the bash FAQ (ftp://ftp.cwru.edu/pub/bash/FAQ) mentions a few ways to fix this, some which appear to leave things as they are for people using emacs mode without screwing over people who prefer vi mode. In particular, it says: ...bracket the key bindings in /etc/inputrc with these lines $if mode=emacs [...] $endif That seems like a very easy fix.