Bug 2397 - "set -o vi" does not work because of new INPUTRC setting
Summary: "set -o vi" does not work because of new INPUTRC setting
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
: 2530 2738 3323 3521 3528 3702 4037 14638 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-04-28 17:12 UTC by lu
Modified: 2007-04-18 16:22 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-10-05 05:51:34 UTC
Embargoed:


Attachments (Terms of Use)

Description lu 1999-04-28 17:12:12 UTC
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.

Comment 1 lu 1999-04-28 23:52:59 UTC
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.

Comment 2 pwt 1999-04-29 14:22:59 UTC
This bug affects bash version 1 and version 2.

Comment 3 pwt 1999-04-29 18:11:59 UTC
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.

Comment 4 Bill Nottingham 1999-05-04 14:46:59 UTC
*** 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.

Comment 5 juvvadi 1999-05-18 15:45:59 UTC
Contrary to what lu.edu says,
set -o vi
doesn't solve problems either

Comment 6 dharris 1999-05-21 20:26:59 UTC
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...

Comment 7 Dale Lovelace 1999-06-09 19:29:59 UTC
*** 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

Comment 8 Dale Lovelace 1999-06-10 15:24:59 UTC
*** 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...

Comment 9 Jeff Johnson 1999-06-17 18:21:59 UTC
*** 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.

Comment 10 Jay Turner 1999-06-24 13:32:59 UTC
*** 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.

Comment 11 schlut 1999-06-24 14:00:59 UTC
I wasn't logged in when I made the comment above about commenting
out INPUTRC in /etc/profile.

Comment 12 Bill Nottingham 1999-08-19 19:48:59 UTC
*** 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.

Comment 13 Cristian Gafton 1999-10-05 05:51:59 UTC
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

Comment 14 Glen Foster 2000-07-30 20:34:02 UTC
*** Bug 14638 has been marked as a duplicate of this bug. ***

Comment 15 C.Laurence Gonsalves 2003-10-12 21:25:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.