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 > command. > > 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. BTW, I'm using a two line prompt $ set | grep ^PS1 PS1='\...@\h:\w [\t]\n\$ ' and noticed that sometimes when I start a new urxvt(c) the prompt is not printed correctly: everything up to the newline is fine, but then the newline and the \$ are not output, and the cursor shows up in the second to last column of the same line; a Ctrl-L restores the prompt to normal. If this happens, then Ctrl-C does not work (in the same way you described). And if this does not happen, Ctlr-C does work. Thus this seems to be another manifestation of the same problem. Because it mostly works I haven't debugged this further yet... Regards, Jukka -- This email fills a much-needed gap in the archives. _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
