Raw_input with readline in a daemon thread makes terminal text disappear

[Aahz]

In article <mailman.1730.1256035236.2807.python-list at python.org>,
John O'Hagan <research at johnohagan.com> wrote:
>On Mon, 19 Oct 2009, Aahz wrote:
>> In article <mailman.1448.1255618675.2807.python-list at python.org>,
>> John O'Hagan <research at johnohagan.com> wrote:
>>> 
>>>I'm getting input for a program while it's running by using raw_input in a
>>>loop in separate thread. This works except for the inconvenience of not
>>> having a command history or the use of backspace etc.
>>>
>>>That can be solved by loading the readline module; however, it results in
>>> a loss of visible access to the terminal when the program ends: nothing
>>> is echoed to the screen and the history is invisible (although it is
>>> there - hitting return executes whatever should be there normally). The
>>> only way to get it back is to close the terminal and open a new one.
>> 
>> Can you restructure your program so that input gets handled in the main
>> thread?
>> 
>I can, but then I can't Ctrl+C out of the main program (which is a thread in 
>that scenario). This applies with or without readline loaded. I have seen 
>some, um, threads on this subject, and from memory it's complicated.

I don't have time to test this myself, but this doesn't sound right; my
experience is that it's the main thread that needs to be handling input
in order to correctly catch signals (such as ctrl-C).

>The raw_input and readline docs mention that the former uses the latter
>for history and line-editing features. I haven't been able to find out
>exactly how, but a theory occurs to me that the pair together somehow
>temporarily "steal" control of the command-line while raw_input is
>accepting input - at least this would explain the missing command-line
>when raw_input is terminated in a daemon thread.

Certainly; readline is using the tty interface.

>Since posting this question, I worked around it by making the input
>loop thread non-daemon, and having it run only while an Event object's
>flag is set - it's unset at the end of the program. That way, I just
>have to hit return one more time to let the loop find the unset flag
>and we can exit cleanly.

Unless you can get your input running in the main thread, this is
probably the best you can do.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Member of the Groucho Marx Fan Club