In article <mailman.1730.1256035236.2807.python-l...@python.org>, John O'Hagan <resea...@johnohagan.com> wrote: >On Mon, 19 Oct 2009, Aahz wrote: >> In article <mailman.1448.1255618675.2807.python-l...@python.org>, >> John O'Hagan <resea...@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 (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ Member of the Groucho Marx Fan Club -- http://mail.python.org/mailman/listinfo/python-list
