strange behaviour of bash-4.0.17 when used in urxvt
thomas.adam22 at gmail.com
Thu Apr 9 01:25:35 CEST 2009
2009/4/9 Jukka Salmi <j+urxvt at 2009.salmi.ch>:
> Nicolai Lissner --> rxvt-unicode (2009-04-08 05:07:41 +0200):
>> I experience really strange behaviour with bash-4 cmdline in urxvt.
>> When I type in a command in the bash-4 shell and change my mind
>> while typing, I usually can use ctrl+c to cancel the input,
>> getting a new prompt. Starting with bash-4 this doesn't work
>> anymore, so I have to use backspace to remove anything I've
>> typed which is obviously annoying.
>> This happens only with the _first_ shell (i.e. the bash
>> instance called by urxvt). When I start a subshell by just
>> running "bash" inside this shell, the new shell just
>> behaves as it should. And yes, I have to run a subshell,
>> "exec bash" doesn't solve the problem.
>> As this didn't happen with bash-3.x one might think it is a
>> problem in bash-4, but actually all other terminals I've tested
>> (xterm, aterm, konsole) don't have this problem. So this is
>> weird problem with the combination of bash4 with urxvt only.
>> I already compared the output of "stty -a" of a bash4-instance
>> that has the problem with "stty -a" of an instance that hasn't:
>> no difference.
>> In a shell that has this problem, I also cannot cancel
>> "read -n 1", which should actually return after reading a single
>> char, so it seems bash4 doesn't even receive the keystroke,
>> but urxvt prints "^C" in this case (although without effect)
>> In a subshell (without the problem) "^C" still prints out when
>> pressed while running "read -n 1" but actually cancels the
>> For now, I found a workaround by starting a subshell via .bashrc
>> depending on the current SHLVL, but that's a waste of RAM and a
>> very dirty workaround, I just have no idea what actually might
>> cause this problem.
>> I'm using rxvt-unicode (urxvt) v9.06 with bash-4.0.17 (however
>> the problem appeared with the very first bash4 versions already)
>> Very confusing.
> I think I'm seeing the same problem on NetBSD/i386 with urxvt 9.06, bash
> 4.0.0(1) and dwm (a tiling wm, slightly modified version 5.5). However,
> the problem happens only once in about five to ten times a new urxvt(c)
> is started, so there's definitely a race condition.
I don't suppose you're using the tabbed extension, are you?
All of the symptoms described here so far, irrespective of the claims
that bash4 does something odd (which I think is a red-herring), I have
seen when using the tabbed extension. I don't have the time, or the
inclination to work out why, but I do notice that when starting urxvt
with the tabbed extension, the first prompt doesn't do tab-completion
or anything else, until I hit ^C then it works fine.
-- Thomas Adam
More information about the rxvt-unicode