Raw_input with readline in a daemon thread makes terminal text disappear
John O'Hagan
research at johnohagan.com
Tue Oct 20 06:40:24 EDT 2009
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.
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.
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.
This has the unplanned benefit that the closing of the separate output window
(a terminal in a subprocess, listening on a socket) can also wait on the same
flag, so the workaround looks as if it's on purpose. ;)
Still open to any cleaner suggestions, of course.
Regards and thanks,
John
More information about the Python-list
mailing list