classification
Title: Management of KeyboardInterrupt in cmd.py
Type: enhancement Stage: test needed
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Philip.Zerull, alexandre.vassalotti, draghuram, gvanrossum, isandler, ngie, stephbul
Priority: low Keywords: patch

Created on 2007-10-18 12:51 by stephbul, last changed 2012-10-27 20:15 by Philip.Zerull. This issue is now closed.

Files
File name Uploaded Description Edit
cmd.py stephbul, 2007-10-18 12:51
cmd.py.keyboardinterrupt.patch stephbul, 2007-10-19 12:27
cmd.diff draghuram, 2007-10-19 19:43
keyboardcmd.py Philip.Zerull, 2012-10-27 20:15
Messages (23)
msg56524 - (view) Author: BULOT (stephbul) Date: 2007-10-18 12:51
According to me, the Ctrl-C is not managed correctly in cmd.py. Ctrl-C
generates a a KeyboardInterrupt exceptions, and only EOFError is
managed. I propose to manage KeyboardInterrupt on line 130:
                               print 'are you sure you want to exit? y/n'
                                answer =''
                                while (answer != 'y') & (answer != 'n'):
                                        answer = raw_input()
                                if answer == 'y':
                                        exit(0)

Here is attached my new cmd.py
Hope ti will help.
msg56529 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-18 16:55
Would you mind submitting a patch instead of a whole new file?
msg56551 - (view) Author: BULOT (stephbul) Date: 2007-10-19 12:27
Hello,
Here is my patch for cmd.py 
Regards
stephbul
msg56557 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-19 17:34
Hmm...  I don't think this is the right thing to do.  The code is broken
in several ways.  I recommend you find someone to help you come up with
a better patch in comp.lang.python.
msg56561 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-10-19 19:43
I tested cmd.py on Linux and two things (including the one reported by
OP) looked odd to me.

1) CTRL-D produces a message "*** Unknown syntax: EOF". 
2) CTRL-C produces a KeyboardInterrupt exception and the session terminates.

I am attaching a patch that changes the behaviour to a more typical one
(at least, in IMHO). It terminates the session on CTRL-D and it just
ignores CTRL-C. Both of these can be overridden, if required. If the
patch is accepted, a doc change would be required in addition to the
change in doc string. I tested the patch on Linux and Windows.
msg56606 - (view) Author: BULOT (stephbul) Date: 2007-10-20 15:45
Well, I made it with a diff -ruN, it works fine on my ubuntu.
It is only a ctrl-C management only, not a ctrl-D.
What do you mean by broken?
Regards.
Stephbul

2007/10/19, Guido van Rossum <report@bugs.python.org>:
>
>
> Guido van Rossum added the comment:
>
> Hmm...  I don't think this is the right thing to do.  The code is broken
> in several ways.  I recommend you find someone to help you come up with
> a better patch in comp.lang.python.
>
> ----------
> keywords: +patch
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1294>
> __________________________________
>
msg58168 - (view) Author: Alexandre Vassalotti (alexandre.vassalotti) * (Python committer) Date: 2007-12-04 00:28
First, I would like to say thank you both for spending your time trying
to do a contribution to Python.

However, I believe the current behavior of cmd.py is correct. The module
documentation states clearly that "End of file on input is processed as
the command 'EOF'." For the KeyboardInterrupt issue, it thinks the
exception should be handled by the application with a try-statement. For
example,

   >>> 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
inappropriate, please request with an appropriate explanation to reopen it.
msg58173 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-12-04 03:55
My patch adds very sensible default behaviour when Ctrl-C or Ctrl-D
are entered. It follows the tradition of many unix programs such as
bash and bc which exit on Ctrl-D and ignore Ctrl-c in one way or
another. Most importantly, a user can always override the behaviour
but I expect the added functionality would suffice in most if not all
cases. Do you mind opening the issue in the hope that we can have more
comments?
msg58174 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-12-04 04:11
I will look into this for 2.6. No promises. Somebody ought to check 
whether this does not cause problems for pdb.
msg58175 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-12-04 04:36
> I will look into this for 2.6. No promises. Somebody ought to check
> whether this does not cause problems for pdb.

Thanks. I will check about pdb tomorrow.
msg58498 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-12-12 15:24
"Tomorrow" took a while to come by :-)

With out the patch, pdb prints this on Ctrl-C:

"KeyboardInterrupt
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program"

With the patch, pdb prompt appears again. Ctrl-D change doesn't effect
pdb because do_EOF() is already implemented. My test was on SuSE 10 Linux.
msg59904 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2008-01-14 16:49
bugday task?
msg59906 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-14 18:43
To mark things for the bugday, set the 'easy' keyword.

However, this particular one is IMO too subtle for a bugday, witness the
discussion here.  Perhaps a bugday could come up with an ultimate patch,
but I'd be hesitant to submit it without having reviewed it personally.
msg59970 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2008-01-15 15:15
Ok. BTW, can I get tracker permissions? I will try to check old bugs to
update their information and if required, close them.
msg59976 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-15 17:44
I've added developer status to your username. Let me know if it doesn't
work.
msg59980 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2008-01-15 18:23
> I've added developer status to your username. Let me know if it doesn't
> work.

It does. Thanks.
msg95051 - (view) Author: Ilya Sandler (isandler) Date: 2009-11-09 01:22
Is not this patch backward incompatible?

E.g any cmd-based application which expects Ctrl-C to propagate to the
top level will be broken by this patch.

As for pdb, I don't think pdb will benefit from this patch: as I believe
that pdb needs something along the lines of patch #7245 for Ctrl-C
(temporary interrupt of execution with ability to resume similar to what
gdb does)
msg95146 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2009-11-11 18:49
On Sun, Nov 8, 2009 at 8:22 PM, Ilya Sandler <report@bugs.python.org> wrote:

> Is not this patch backward incompatible?
>
> E.g any cmd-based application which expects Ctrl-C to propagate to the
> top level will be broken by this patch.

But currently, CTRL-C terminates the session instead of propagating
upstream. The only way it would do so is if do_KeyboardInterrupt() is
implemented in which case, the behaviour would remain same even with
the patch.
msg95174 - (view) Author: Ilya Sandler (isandler) Date: 2009-11-13 07:00
> But currently, CTRL-C terminates the session instead of propagating
upstream

I am not sure I understand: currently Ctrl-C generates a
KeyboardInterrupt, which can be caught by the  application which can
then decide how to proceed (in particular it  can start another command
loop or exit with a meaningful message or anything else).

This patch would suppress KeyboardInterrupt and thus interfere with such
applications. Or am I missing something?
msg95177 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2009-11-13 14:56
> I am not sure I understand: currently Ctrl-C generates a
> KeyboardInterrupt, which can be caught by the  application which can
> then decide how to proceed (in particular it  can start another command
> loop or exit with a meaningful message or anything else).
>
> This patch would suppress KeyboardInterrupt and thus interfere with such
> applications. Or am I missing something?

I checked the patch and tested with python from trunk. You are right
that the patch catches KeyboardInterrupt thus interfering with any
applications that expect it to be propagated upstream.  Perhaps, this
can be made conditional so that we can keep both behaviors.

But CTRL-D processing doesn't suffer from any backwards compatible
issues and that part of the patch should be able to be applied safely.
msg95179 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2009-11-13 15:56
I don't think this is a good idea.
msg145854 - (view) Author: Enji Cooper (ngie) * Date: 2011-10-18 19:03
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
command subcommand_1

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.
msg173968 - (view) Author: Philip Zerull (Philip.Zerull) Date: 2012-10-27 20:15
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.
History
Date User Action Args
2012-10-27 20:15:32Philip.Zerullsetfiles: + keyboardcmd.py
nosy: + Philip.Zerull
messages: + msg173968

2011-10-18 19:03:43ngiesetnosy: + ngie
messages: + msg145854
2009-11-13 15:56:02gvanrossumsetstatus: open -> closed
resolution: rejected
messages: + msg95179
2009-11-13 15:55:35gvanrossumsetfiles: - unnamed
2009-11-13 14:56:10draghuramsetmessages: + msg95177
2009-11-13 07:00:05isandlersetmessages: + msg95174
2009-11-11 18:49:44draghuramsetmessages: + msg95146
2009-11-09 01:22:03isandlersetnosy: + isandler
messages: + msg95051
2009-05-13 22:07:47ajaksu2setstage: test needed
versions: + Python 2.7, Python 3.2, - Python 2.6
2008-01-15 18:23:47draghuramsetmessages: + msg59980
2008-01-15 17:44:37gvanrossumsetmessages: + msg59976
2008-01-15 15:15:30draghuramsetmessages: + msg59970
2008-01-14 18:43:46gvanrossumsetmessages: + msg59906
2008-01-14 16:49:02draghuramsetmessages: + msg59904
2007-12-12 15:24:23draghuramsetmessages: + msg58498
2007-12-04 04:36:26draghuramsetmessages: + msg58175
2007-12-04 04:11:05gvanrossumsetstatus: closed -> open
resolution: rejected -> (no value)
messages: + msg58174
versions: + Python 2.6, - Python 2.5
2007-12-04 03:55:29draghuramsetmessages: + msg58173
2007-12-04 00:28:31alexandre.vassalottisetstatus: open -> closed
nosy: + alexandre.vassalotti
messages: + msg58168
priority: low
components: + Library (Lib), - None
type: behavior -> enhancement
resolution: rejected
2007-10-20 15:45:41stephbulsetfiles: + unnamed
messages: + msg56606
2007-10-19 19:43:57draghuramsetfiles: + cmd.diff
nosy: + draghuram
messages: + msg56561
2007-10-19 17:34:29gvanrossumsetkeywords: + patch
messages: + msg56557
2007-10-19 12:27:53stephbulsetfiles: + cmd.py.keyboardinterrupt.patch
messages: + msg56551
2007-10-18 16:55:53gvanrossumsetnosy: + gvanrossum
messages: + msg56529
2007-10-18 12:51:56stephbulcreate