Bug 21222 - set -o vi not working for non-root users
Summary: set -o vi not working for non-root users
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash   
(Show other bugs)
Version: 7.0
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
: 23014 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-22 03:29 UTC by Bruce K. Nivens
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-26 17:33:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bruce K. Nivens 2000-11-22 03:29:40 UTC
bash is only allowing root to invoke vi-style command-line editing.  When
non-root users try to invoke it, the shell acts as though it hasn't been
set.  set -o vi is accepted and processed without error.  A followup set -o
shows that vi has been set.  However, pressing [Esc] to invoke vi command
mode has no effect.  The next key pressed simply results in an alarm
(beep), as if though set -o vi had not been executed.  Again, this DOES
work for root, but not for non-root users.  I've scanned your site for
mention of this, and I've seen none.  I checked out the COMPAT file for
bash-2.04, and it doesn't mention this either.  "Jp" at Redhat tells me
that he believes that this functionality has been removed for non-root
users, but advised me that I could go ahead and report this as a bug.  Is
this a bug, or a "feature?"  (If this is an intentional change, could
someone please tell me why on God's earth you would remove one of the best
features of a command-line based shell???!!!)  Please help!

Comment 1 Shane Owenby 2000-11-28 17:16:10 UTC
This is how I fixed it.
(sopic) /etc% diff -u inputrc.orig inputrc
--- inputrc.orig        Fri Nov 17 15:09:53 2000
+++ inputrc     Fri Nov 17 15:10:10 2000
@@ -1,26 +1,7 @@
 # do not bell on tab-completion
-#set bell-style none
+set bell-style none
 set meta-flag on
 set input-meta on
 set convert-meta off
 set output-meta on
-"\eOd": backward-word
-"\eOc": forward-word
-# for linux console
-"\e[1~": beginning-of-line
-"\e[4~": end-of-line
-"\e[5~": beginning-of-history
-"\e[6~": end-of-history
-"\e[3~": delete-char
-"\e[2~": quoted-insert
-# for xterm
-"\eOH": beginning-of-line
-"\eOF": end-of-line
-#for freebsd console
-"\e[H": beginning-of-line
-"\e[F": end-of-line
(sopic) /etc% 

Comment 2 Bruce K. Nivens 2000-11-28 20:37:29 UTC
Sorry.  With all due respect, this is not a "fix."  The shell is supposed to allow command-line editing in its default state, as long as set -o vi has been 
invoked.  I shouldn't have to tweak anything to get this feature to work, and I shouldn't have to set up a work-around.  The editing feature works for root 
and for nobody else, and this is -- plainly and simply -- a bug.

Comment 3 Bruce K. Nivens 2000-11-29 21:06:42 UTC
Let me add that I'm appreciative of shane@collab.net for the information about how he "fixed" the problem by revising the /etc/inputrc file.  I realize I might 
have come across as unappreciative in my previous additional comment.

The point I was trying to make is that root and non-root users are all pointed to the same /etc/inputrc file via the INPUTRC environment variable (I have 
confirmed this on my system).  root and non-root users are using the same instance of bash.  There is no documented difference in expected behavior of 
command-line editing between root and non-root users.

And yet, there IS a difference.  When shane@collab.net changed a line and deleted some others from /etc/inputrc, this should have changed the behavior 
of the command-line editing for EVERYONE, not just non-root users.  It still doesn't explain why -- given the same /etc/inputrc file to init Readline with -- 
there is a behavioral difference between root and non-root.  In previous versions of RH, the default installation has not had this problem.  The new version 
of bash (2.04) may be the culprit, or perhaps the Readline library it's linking to is the culprit.  Perhaps a permission setting is screwed up somewhere?

I'm investigating this in my spare time, but it would be great if someone could pinpoint the root cause (no pun intended) of this problem.

Comment 4 Need Real Name 2000-12-06 15:36:36 UTC
I've also worked around this very annoying bug for a long time.  What I've
discovered is that
it works for non root users if you don't add set -o vi to .profile or it's
friends.  You log in and
type set -o vi by hand and then it works properly.  I certainly with gnu.org
would fix it.

Comment 5 Bruce K. Nivens 2000-12-07 01:39:44 UTC
In response to kitchen@pelletron.com's comments:  My experience has not been the same as yours.  This is the first version of bash I've had this 
problem with.  Furthermore, in the current version, it doesn't matter if you put set -o vi in .profile or if you type it in after you log in.  The problem is the 

The fix provided by shane@collab.net cures the symptom.  The problem is, that it shouldn't have made a difference.  That is, root and the non-root users 
were all looking at /etc/inputrc as installed by the RedHat installer.  set -o vi worked with root, and not with anyone else.  Then, I put shane@collab.net's 
changes into /etc/inputrc, and now set -o vi works for everybody!  That's great, except that it doesn't explain why there was a difference in behavior 
between root and non-root users to begin with.  There shouldn't have been.  Perhaps root is not actually looking at the contents of inputrc (even though 
the INPUTRC environment variable was set to /etc/inputrc), or perhaps certain inputrc options are ignored by root?  There is no documentation supporting 
a difference in behavior.

Comment 6 Bernhard Rosenkraenzer 2001-01-08 15:56:13 UTC
*** Bug 23014 has been marked as a duplicate of this bug. ***

Comment 7 Shane Owenby 2001-04-26 17:33:16 UTC
FWIW, this seems to have been fixed for me in 7.1, Shane

Comment 8 Bernhard Rosenkraenzer 2001-05-21 19:49:31 UTC
This is finally fixed in the current set of related packages (bash, readline, 

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