Why do we need to send these end commands back and forth? They are constants. Also end is a very important one (arguably the most important one as it's in the example).

They're constants, but they're not necessarily the same constants for the client and the server, since they can be running different versions of Python.

If the attaching client is running 3.14.9 and the remote PDB server is running 3.14.0, it's possible that the client will think that some command should terminate the command list, and send a command list to the server that the server thinks is incomplete because it doesn't recognize that terminator. If that happened, we'd be out of sync - the server would still be waiting for more lines, and the client would think that it's done sending lines.

That said, perhaps I'm being overly defensive, and we shouldn't expect any new command to ever be added after 3.X final. But the risk of getting it wrong is leaving you with a broken debugger session that might only be able to be fixed by killing the client.

Another possible option is to be defensive in the:

        for line in commands:
            if self.handle_command_def(line):
                break

loop below. We could say that loop must break, and that if it doesn't, it can only mean that we got a list that was unterminated, and so we should roll back to the old set of commands. If you prefer that over sending list of early-command-terminators back over the wire, I'm fine with that.

That'd just be something like (pseudocode):

        saved = old_commands_for_breakpoint(bnum)
        for line in commands:
            if self.handle_command_def(line):
                break
        else:
            self.error("Incomplete command list!")
            set_commands_for_breakpoint(bnum, saved)

the server would still be waiting for more lines, and the client would think that it's done sending lines.

That won't happen. When the client sent the commands as a list, the server will just finish the list and consider it done for the commands. Nothing worse would happen.

Also, I don't expect the list of resuming commands to change. And as discussed elsewhere, I don't think we should support cross version debugging.

I just tested it and CTRL+D does not work either (to terminate the commands).

That won't happen. When the client sent the commands as a list, the server will just finish the list and consider it done for the commands. Nothing worse would happen.

Ah, you're right - I misremembered and thought that _RemotePdb sets self.commands_defining = True, but it doesn't (it used to in one of my earlier iterations).

OK, in that case, the only reason I can think of to send the list of resuming commands from the remote to the client is aliases. Currently I'm not handling that, and I'm just hardcoding, but in regular PDB you can:

(Pdb) alias blah cont
(Pdb) import functools
(Pdb) b functools.cache
Breakpoint 1 at /opt/bb/lib/python3.13/functools.py:676
(Pdb) commands
(com) p "hello from breakpoint"
(com) blah
(Pdb)

Note that blah ended the command list. The only way we can support that for remote PDB is to send the list of resuming commands from the server to the client. But, I also don't care much if we support that. As you say, if we don't, the only impact is that the user needs to a) use the regular command instead of the alias, or b) add an end command.

That seems fine to me. I think that having the resuming commands end the command list is a weird feature anyway, but I was aiming for feature parity.

So: if you care about aliases for resuming commands ending the commands list, I'll keep this code and update it to also send the list of aliases that expand to one of the commands in the list.

If you don't care about aliases for resuming commands ending the command list, I'm happy to hardcode the list client-side instead.

I just tested it and CTRL+D does not work either (to terminate the commands).

Not for regular PDB either, so that's fine.

But ctrl-c just kills the whole remote pdb client, that's wrong.

Also end is a very important one

lol oops, that's what I get for focusing on edge cases 🤣

Fixed 'end' and ctrl-c in e44a670

I believe the only "correct" way to do this is to send the commands to the server one by one - you'll never get the correct result with client parsing. For example, x = 1;;continue should end the command prompt, and the current client does not do that. Unless you parse everything exactly as the server does, you won't get the same result.

For your blah example - the current code does not handle it, and it would be complicated to make it work properly. If we want to make it right, we need to simulate the send/receive line by line.

The worse case in the current implementation is that the user needs to end the command with an end - that's not too bad. We can do it for now.

For example, x = 1;;continue should end the command prompt, and the current client does not do that.

Oof, yeah. I didn't think about ;;

If we want to make it right, we need to simulate the send/receive line by line.

I can do that. It wouldn't be too tough, and it would wind up looking a lot like interact - set a flag for the "mode", and make it be possible for the client to return to command mode (on ctrl-c or ctrl-d) or for the server to (when the command list is terminated).

I understand how to do this, and it wouldn't be difficult, but it would be almost exactly as complex as interact, for better or worse.

Addressed in 600aa05