You can use the pwnlib.gdb to interface with gdb.

You can use the gdb.attach() function: From the docs:

bash = process('bash')

# Attach the debugger
gdb.attach(bash, '''
set follow-fork-mode child
break execve
continue
''')

# Interact with the process
bash.sendline('whoami')

or you can use gdb.debug():

# Create a new process, and stop it at 'main'
io = gdb.debug('bash', '''
# Wait until we hit the main executable's entry point
break _start
continue

# Now set breakpoint on shared library routines
break malloc
break free
continue
''')

# Send a command to Bash
io.sendline("echo hello")

# Interact with the process
io.interactive()

The pwntools template contains code to get you started with debugging with gdb. You can create the pwntools template by running pwn template ./binary_name > template.py. Then you have to add the GDB arg when you run template.py to debug: ./template.py GDB.

If you get [ERROR] Could not find a terminal binary to use., you might need to set context.terminal before you use gdb.

If you're using tmux, the following will automatically open up a gdb debugging session in a new horizontally split window:
context.terminal = ["tmux", "splitw", "-h"]

And to split the screen with the new gdb session window vertically:
context.terminal = ["tmux", "splitw", "-v"]

(Note: I never got this part working, so idk if it'll work. Tell me if you get the gdb thing working).
(To use tmux, install tmux on your machine, and then just type tmux to start it. Then type python template.py GDB.

If none of the above works, then you can always just start your script, use ps aux, find the PID, and then use gdb -p PID to attach to the running process.

First I'd only keep the terminal executable names in the list and dynamically determine their actual paths based on the PATH env var - depending on the distribution and/or the installation options they might be in other locations. Or use which <terminal executable> which does that for you.

I'd use xterm as the final fallback terminal - it's pretty much standard on any X-Windows installation.

Other convenience considerations:

• check if DISPLAY is set - if it's not most likely the terminals won't run
• try to determine the actual graphics environment and first try the more appropriate one for it. WINDOWMANAGER may help. Specific window managers typically set their own env vars, for example in my case KDE sets: KDE_SESSION_UID, KDE_FULL_SESSION, KDE_MULTIHEAD, KDE_SESSION_VERSION.