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
Management of KeyboardInterrupt in cmd.py #45635
Comments
According to me, the Ctrl-C is not managed correctly in cmd.py. Ctrl-C Here is attached my new cmd.py |
Would you mind submitting a patch instead of a whole new file? |
Hello, |
Hmm... I don't think this is the right thing to do. The code is broken |
I tested cmd.py on Linux and two things (including the one reported by
I am attaching a patch that changes the behaviour to a more typical one |
Well, I made it with a diff -ruN, it works fine on my ubuntu. 2007/10/19, Guido van Rossum <report@bugs.python.org>:
|
First, I would like to say thank you both for spending your time trying However, I believe the current behavior of cmd.py is correct. The module >>> import sys, cmd
>>> c = cmd.Cmd()
>>> try:
... c.cmdloop()
... except KeyboardInterrupt:
... print "\nGot keyboard interrupt. Exiting..."
... sys.exit(0)
...
(Cmd) ^C
Got keyboard interrupt. Exiting... I am closing and marking this bug as rejected. If you feel this is |
My patch adds very sensible default behaviour when Ctrl-C or Ctrl-D |
I will look into this for 2.6. No promises. Somebody ought to check |
Thanks. I will check about pdb tomorrow. |
"Tomorrow" took a while to come by :-) With out the patch, pdb prints this on Ctrl-C: "KeyboardInterrupt With the patch, pdb prompt appears again. Ctrl-D change doesn't effect |
bugday task? |
To mark things for the bugday, set the 'easy' keyword. However, this particular one is IMO too subtle for a bugday, witness the |
Ok. BTW, can I get tracker permissions? I will try to check old bugs to |
I've added developer status to your username. Let me know if it doesn't |
It does. Thanks. |
Is not this patch backward incompatible? E.g any cmd-based application which expects Ctrl-C to propagate to the As for pdb, I don't think pdb will benefit from this patch: as I believe |
On Sun, Nov 8, 2009 at 8:22 PM, Ilya Sandler <report@bugs.python.org> wrote:
But currently, CTRL-C terminates the session instead of propagating |
I am not sure I understand: currently Ctrl-C generates a This patch would suppress KeyboardInterrupt and thus interfere with such |
I checked the patch and tested with python from trunk. You are right But CTRL-D processing doesn't suffer from any backwards compatible |
I don't think this is a good idea. |
I realize that this bug is closed, but I just had a comment to make. Handling EOF is simple: def do_EOF(self, arg):
pass For my purposes I want to raise an EOFError so I can trickle up the chain to the appropriate caller because I'm coding a CLI where I have a nested set of commands, e.g. command subcommand_0 I'd like the behavior to match what's done in Cisco IOS or IronPort's CLI (to some degree). The only part that's annoying is that I have to hide do_EOF in the help and completion output, otherwise the user will see the handler when completing or running help, but I'll bring that up in another issue. |
Hello, Being of a similar mindset to draghuram on the do_KeyboardInterrupt idea and thought I'd implement it as a subclass. While this probably wasn't fully implemented correctly, I think it provides an interesting solution to stephbul's frustrations and won't break anything. I'm not suggesting that this be included in the standard library but just thought you all might find it interesting. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: