Re: [Python-Dev] test_curses
Georg Brandl [EMAIL PROTECTED] writes: Well, this still has the faint whiff of impossibility about it. Are you sure it's setupterm() that's doing the damage? Can you reproduce interactively? Yep. Alone, the setupterm call [curses.setupterm(sys.__stdout__.fileno())] does nothing remarkable, but when it is done inside of curses.initscr() / curses.endwin() the terminal is not restored properly. Ah! That does indeed make some small amount of sense. If setupterm() is to be tested, I think it should be executed before initscr(). Sounds good. What are you waiting for? :) Cheers, mwh -- etrepum Jokes around here tend to get followed by implementations. -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Georg Brandl [EMAIL PROTECTED] writes: Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. Oh. Maybe I'm out of date. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. Right, so it definitely sounds like the terminal is in raw mode. Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Well, this still has the faint whiff of impossibility about it. Are you sure it's setupterm() that's doing the damage? Can you reproduce interactively? Cheers, mwh -- You can remove divmod() when I'm dead. Before then, it stays. I'm sure all will agree that's a reasonable compromise. -- Tim Peters negotiating on python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. Oh. Maybe I'm out of date. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. Right, so it definitely sounds like the terminal is in raw mode. Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Well, this still has the faint whiff of impossibility about it. Are you sure it's setupterm() that's doing the damage? Can you reproduce interactively? Yep. Alone, the setupterm call [curses.setupterm(sys.__stdout__.fileno())] does nothing remarkable, but when it is done inside of curses.initscr() / curses.endwin() the terminal is not restored properly. If setupterm() is to be tested, I think it should be executed before initscr(). regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Cheers, mwh -- #ifndef P_tmpdir printf( Go buy a better computer ); exit( ETHESKYISFALLINGANDIWANTMYMAMA ); -- Dimitri Maziuk on writing secure code, asr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. I just looked, my .profile contains stty sane cr0 pass8 dec. Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
