0

I automate my gdb script like this

gdb -q --args the_program <<EOL
# breakpoints etc.
run
EOL

Works fine, however when interrupting the running process with Ctrl+C, the entire process falsely exits:

Quit anyway? (y or n) [answered Y; input not from terminal]

, meaning gdb is not interactive anymore. How do I prevent this?

For some reason, the interrupt signal works fine when using an external commands file like gdb ... -x the_commands_file. But this question is about the stdin-way. Is there a possibility to send the desired commands via stdin but still be able to keep interaction possible afterwards?

phil294
  • 10,038
  • 8
  • 65
  • 98
  • Here's how to use `expect` to do this: https://unix.stackexchange.com/questions/97410/why-is-expects-interact-command-not-working – Mark Plotnick Jul 14 '17 at 14:30
  • @MarkPlotnick about your previous comment: I tried https://stackoverflow.com/a/5852578/3779853. This *does* change the behaviour, however when the commands include a `run` (like `(echo run && cat) | gdb ...`), an interrupt leads to a quit again. // Expect would surely work – phil294 Jul 14 '17 at 14:42
  • My previous comment, which I deleted after I found an existing answer on unix.stackexchange.com, suggested writing to `/proc/pid/fd/0` or using `expect`. Using `(echo ...; cat) | ...` would be fine for a noninteractive command, but not for gdb, where you'd want interrupts and character-at-a-time input to work. Typing ^C kills the cat. – Mark Plotnick Jul 14 '17 at 14:55

0 Answers0