(1) why do we need two instructions to do the same thing?
(2) why add a feature and not document it?
(3) where is the test?

(1) BecauseEOF is a special command triggered when user "inputs" EOF (Ctrl+D on Linux). It's not something we added, it's something we need to deal with. Users will doCtrl+D as a habit from all the other similar usages and expect a reasonable result. Currently the behavior is pretty bad.

(Pdb) commands 1(com) (com) (com) (com) (com) (com)

(2) Like I said, this is a reaction to a very natural user input. I think that's a very expected behavior. However, we can add something incommands command saying that inputting anEOF character will also exit thecommands command.

(3) The test involving EOF is not easy to test, especially if you still want to input something after. Currentlypdb does not really test it. One way around this is to use"EOF" as an explicit command to simulate theEOF user inputs. That would make the test super trivial to write. We are relying oncmd.Cmd to convertCtrl+D (Ctrl+Z on Windows I believe) to the correctEOF command. Does that sound reasonable to you?

I see. That context can be encoded in a test. Add the trivial test for 'EOF' and put a comment there that this is what cmd produces for Ctrl+D.

Okay I added a basic test in an existing test case. Notice that<BLANKLINE> appears in the output becauseEOF\n creates a new line butCtrl-D will not have that new line. SoEOF\n results in an extra new line compared toCtrl-D. We don't want the user to stay on the same line afterCtrl-D so we need to output a new line in that command.