New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow subprocesses to continue on after KeyboardInterrupt #406
Comments
Rather, there's no exit code ( So we probably do need to preserve the fact that a KeyboardInterrupt occurred (as a nearby TODO mentioned, actually) and put in code 130 if the subproc has none of its own. |
Ah, another (or the real) issue is that our current logic is structured as: try:
self.wait()
except BaseException as e:
# handle exceptions here, including KeyboardInterrupt
# continue to shutdown step So even if we "neuter" the KeyboardInterrupt, it doesn't matter, we stop waiting and instead act as if the subprocess has closed - which is at least one reason why we end up with a Need sound logic that can handle arbitrary numbers of KeyboardInterrupts and return to waiting, but which will break out otherwise. |
Got that sorted, but amusingly, vim doesn't actually register the Ctrl-C keystroke unless I preface it with Ctrl-V. Which makes sense, because, we're never actually submitting anything on stdin (unless we use Ctrl-V to prevent the actual interrupt)! (And it is, presumably, self-resistant to SIGINT. I think.) Fabric (and 2) do send Will experiment. |
Yup, that makes vim work fine. Also appears to work for Plus, when pty=False, Other things like Fabric v2's got some preemptory comments in its This is somewhat problematic because it means it's harder for us to reliably act like "regular" apps / straight up But here, in either case, it appears to have a real return code - how can we tell a |
Seems like it's a tradeoff between "be as-correct-as-possible re: Ctrl-C submission to subprocess" and "have a super correct exit code". Personally, I'd much rather have apps that care hard about Ctrl-C get as-useful-as-possible behavior, than have a super-duper-correct exit code in situations where it's kinda screwy. In other words, this feels like another case of interactive, side-effect-oriented Main downside I can see is |
Behavior seems same on Linux so far, FTR. |
Cool, glad I looked. Of course, then I have to wonder how one does get the "right" exit code. Offhand guess is that it's up to us to determine, since we're basically now the "shell" running it, so we could use this as the guide re: whether to continue exiting 130. Question would then be, what other situations besides Ctrl-C could cause |
Right - feels like one of the other siblings of EDIT: ok, yea, On the non-pty ( Still leaves the question of whether to try and act shell-like and transmute a propogated Ctrl-C + an exit of |
Found some nice details on the shell behavior in this SO answer; a tl;dr could be "the 130 you get in bash/zsh is 128 + abs(exit)". But it's very shell specific and varies between shell families. Since Invoke is not itself a shell and doesn't want to be terrifically shelly (outside of how we may still default to Reckon if users complain enough (rather, can make a compelling argument that they absolutely need this "signal + 128" behavior because just the signal value is insufficient...) we could entertain the idea of being 'shell-like' in some situations. Though it'd need to be a good argument. As noted above, my chief concern right now is that we're not exiting 0 incorrectly, and as long as that is the case, arguing over the exit status of a 'real' Ctrl-C'd human-driven Invoke process is secondary. |
Remaining TODO:
|
Discrepancy alert, one I should have noticed above: Subprocess' docs do not say why it uses negative numbers here (and not e.g. a tuple); I'm guessing it's just a way of packing signal-or-regular-exit into a single integer "field"? Either way, this is a bit of an impedance mismatch (or whatever) - there is no "real" exit status code, and we aren't technically a shell, so I think the least-crappy normalization is to actually follow |
OR I could be smarter and only 'normalize' at exit time, leaving the two statuses separate inside EDIT: Double-or: that's actually harder than it looks as it requires us to rip apart more of the return code handling functionality. Already too deep in this rabbit hole so fuckit. Negative numbers it is. |
Don't see a real point to the integration test part of this; it slays me to simply delete all the sweat & tears that went into it during #152 , but all an integration test would do now is prove what I can easily test at the unit level: that the Much simpler functionality == much simpler tests. Which is nice. Just wish I'd done this before wasting all that time earlier. Programming :( |
Still need to deal with the exit code shenanigans and integration tests
Tests all passing locally and on Travis - we're done! Unless I run into brokenness again with my real world use cases. Sigh. |
Semi-spinoff of #58 - some interactive programs want to handle Ctrl-C themselves, but right now, we store
KeyboardInterrupt
while sending the interrupt downstream, and then raise it like any other exception (as well as re-catching it and exiting 130 at the very end. Life's complicated.)This means that mashing Ctrl-C in a REPL (even one that is itself doing
except KeyboardInterrupt
, if it's a Python repl!) or an editor or etc, will immediately exit, even if the subprocess itself would not have.Ideally, fixing this will still allow us to exit with 130 if the subprocess itself does so - a quick attempt at a fix seems to not cause this (e.g.
sleep 60
+ Ctrl-C normally exits 130, but withinrun()
, exits 0.)The text was updated successfully, but these errors were encountered: