Additional to what Patrice has said, debugging ncurses has its own set of challenges. If your IDE can't handle running and debugging a program that uses ncurses, or if you are using a text editor (e.g vi, nano, etc), its nearly impossible to run gdb in a terminal to debug a program that's going to do curses things to the terminal window.
The solution is to use 2 terminal windows. The first we will be using to display the program output. Here you do
$ sleep 10000
This tells us that this terimanl screen is using /dev/pts/0 as its tty port, and we then
for 10,000 seconds - about 2:45 hours - which should be plenty of time to run several debugging sessions. In the other we do
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Here we've started gdb and told it to use /dev/pts/0 as the input/output for the program we're running. This means that all the curses I/O will happen in terminal 1. Since terminal one is executing
, any key presses will be read by the program running under gdb on the other terminal.
Alternatively, if you're comfortable with emacs you only need one terminal and do
$ echo $TERM
$emacs -f gdb
This will start an emacs session, and will prompt you for the name of the program to debug. When you get the emacs gdb buffer, you can tell gdb to use /dev/pts/0 for program in the same way as before. You might also need to do
set env TERM xterm-256color
to get the proper terminal sequences (adjust as per the result of the $TERM variable).