Well, this should tell it all: Would you like to merge these packages? [Yes/No] nos Sorry, response 'no' not understood. [Yes/No] no Quitting. I typed in yes (the long version), then backspaced over it, typed in no, and hit enter. You can see the output. Reproducible: Always Steps to Reproduce: 1.respond with yes 2.delete yes 3.type no 4.hit enter Actual Results: Error. Didn't understand "no" Expected Results: End emerge.
Strange, it seems to work here. It works for me in konsole, xterm, and a plain linux console. I works inside and outside of a screen session too.
I tried it again. Works in a uxterm fine, but its within a screen session there is the problem. It seems to occure when, when you backspace over yes, and it is still visible (bug in screen?), then you have the problem.
Maybe it's some kind of interaction between screen and uxterm. Do you have the same problem in screen on another terminal such as the linux console or a plain xterm?
Yes. Same problem within a standard xterm as well
It works for me here in a screen session under both uxterm and xterm. Here are some of my relevant variables: x11-terms/xterm-222 app-misc/screen-4.0.3 LANG=en_US.UTF-8 What versions and LANG are you using?
x11-terms/xterm Available versions: 222 (~)224 (~)225 app-misc/screen Available versions: 4.0.3 echo "$LANG" en_US.UTF-8 I tried this in a tty w/ screen, and didn't have the same problem. I tried this again w/o screen, and the problem doesn't occur there as well. Seems to only occure when using u/xterm and screen.
So it's an issue between python, screen and xterm, nothing portage can do about by itself.
Well, at least it is known there is a problem with the mix.
I see similar results on my systems: Server: sys-apps/portage-2.1.4.4 sys-libs/ncurses-5.6-r2 sys-libs/readline-5.2_p12-r1 dev-lang/python-2.4.4-r13 net-misc/openssh-4.7_p1-r6 (kernel.org 2.6.22 with vserver patches) Desktop: sys-apps/portage-2.1.4.4 dev-lang/python-2.4.4-r13 sys-libs/readline-5.2_p12-r1 sys-libs/ncurses-5.6-r2 x11-terms/xterm-235 net-misc/openssh-4.7_p1-r6 (kernel.org 2.6.26-rc6) Connecting frop desktop to server via ssh: When typing backspace I get ^H displayed (an not understood by portage) though CTRL+Backspace works as I would expect Backspace to work. Calling portage on the desktop itself: The backspace key works as expected. Calling portage on the desktop within ssh session to localhost: The backspace key does not work anymore (need to do Ctrl+Backspace) and produces same results as for server This looks like it could be related to either ssh alone or some combination of kernel (pts) and ssh...
It doesn't look like there's something to fix here for python.
Portage's userquery() function is used here, and it calls Python's raw_input function: http://docs.python.org/library/functions.html#raw_input I suppose that we could try using sys.stdin.readline() instead, since the implementation details should be a lot simpler than those of raw_input().
Created attachment 322878 [details, diff] use sys.stdin.readline() instead of raw_input() This patch is untested, since I cannot reproduce the problem myself. Save as /tmp/readline.patch and apply as follows: patch /usr/lib/portage/pym/_emerge/userquery.py /tmp/readline.patch