Bug 2738 - inputrc not processed when bash is run
Summary: inputrc not processed when bash is run
Keywords:
Status: CLOSED DUPLICATE of bug 2397
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
: 2404 2736 2852 2921 3116 3376 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-11 16:45 UTC by jay
Modified: 2008-05-01 15:37 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-06-10 15:24:13 UTC
Embargoed:


Attachments (Terms of Use)

Description jay 1999-05-11 16:45:44 UTC
~/.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.

Comment 1 Jeff Johnson 1999-05-15 20:31:59 UTC
*** 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

Comment 2 Jeff Johnson 1999-05-15 22:28:59 UTC
*** 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.

Comment 3 Jeff Johnson 1999-05-16 17:17:59 UTC
*** 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.

Comment 4 bischo 1999-05-21 14:16:59 UTC
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!

Comment 5 bischo 1999-05-21 14:31:59 UTC
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.

Comment 6 thoth 1999-05-23 05:03:59 UTC
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.

Comment 7 thoth 1999-05-23 15:44:59 UTC
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.

Comment 8 Dale Lovelace 1999-05-28 20:26:59 UTC
*** 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

Comment 9 Dale Lovelace 1999-05-28 20:27:59 UTC
*** 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.

Comment 10 Jay Turner 1999-06-10 14:51:59 UTC
*** 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 out bash 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 11 Dale Lovelace 1999-06-10 15:24:59 UTC
*** This bug has been marked as a duplicate of 2397 ***


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