Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Terminal input hidden after quiting subprocess started with `invoke.run` #303
When I run
import invoke @invoke.task def run(): invoke.run('python -m http.server')
and run using
After quiting the server using
Note that running the following does not result in the same issues.
import subprocess subprocess.call('python -m http.server', shell=True)
This was referenced
Jan 18, 2016
@tonysyu I can't replicate this on my end; when I Ctrl-C out of an Invoke-executed
(Side note: One does have to add
My environment is Python 2.7 and/or 3.5, OS X 10.10, Terminal.app, zsh. Tested both the 0.12.0 tag and latest master (which does fix a handful of things, but none directly related to my guesswork above).
If you and/or @presidento can a) try latest master in case I did somehow fix it, and b) if not, share more details about your environment - that'd help. Thanks!
It works well on Windows 10 (64 bit) + Python 3.4 + Invoke 0.12.0
It fails on Ubuntu 15.10 (64 bit) + Python 3.5 + Invoke 0.12.0 and 0.12.1 + bash shell. Surprisingly it works with fish and zsh shells. (Unfortunately bash is the default for most Linux systems as I know.) I have tried with plain bash (without
I hope it helps. Without fixing this we cannot upgrade.
As I suspected it's something to do with how we tickle the controlling TTY to be character buffered; as soon as I comment out these lines, normal terminal behavior resumes immediately after Ctrl-C.
Throwing some debug statements in shows that the
Implies that if this is happening in all situations, zsh is recovering from the lack of terminal settings restoration better than bash does, or the settings change (
Yup, for reasons not well documented, we set the IO worker threads to
Feels like what's necessary is to add a
(I think I still lean towards 'daemon good' insofar as it means failure cases default to "everything exits" instead of "something hangs forever"...)
In trying to test this, I'm finding more evidence that we do need stronger controls on these threads & their lifetime vs the main thread - e.g. if one does, effectively:
try: run('python -m http.server') except KeyboardInterrupt: pass more_things_here()
If you Ctrl-C the server subprocess, once your code is at/past in
Still though, it shows the need for