gdb -batch always exits with status 0

[Gary Benson]

On 17 August 2018 at 19:29, Pedro Alves <palves@redhat.com> wrote:
> To me, it feels like you're not discussing the real issue.
>
> GDB _does_ stop processing scripts on first error.
>
>  $ cat file1
>  fail1
>  fail2
>  fail3
>  $ cat file2
>  fail4
>  fail5
>  fail6
>  $ gdb -q -x file1 -x file2
>  file1:1: Error in sourced command file:
>  Undefined command: "fail1".  Try "help".
>  file2:1: Error in sourced command file:
>  Undefined command: "fail4".  Try "help".
>  (gdb)
>
> Note, fail2, fail3, fail5 and fail6 were not run.
>
> What GDB does not do is consider an error from inside a script
> sourced from the shell command line as reason to fail out.  So for
> example above, I think Gary is arguing that GDB should have behaved
> like this:
>
>  $ gdb -q -x file1 -x file2
>  file1:1: Error in sourced command file:
>  Undefined command: "fail1".  Try "help".
>  (gdb)
>
> I.e., "file2" was not sourced.
>
> In this aspect, "-ex" behaves exactly like "-x" -- you can think
> of -ex as gdb internally pasting the -ex command in a script
> and then sourcing it with -x.

I don't know if I'm overthinking things, but basically I looked at
the different places a command error can occur:

  /etc/gdbinit
  ~/.gdbinit
  -ix
  -iex
  -cd
  -d
  PROG
  -p
  CORE
  .gdbinit in cwd
  -x
  -ex

For some of these it does seem to make sense to exit, e.g. if
processing "-p PID" fails to end up attached to a process.
But nobody is asking for change, nobody's having a problem
with this, so I'm going to leave this here.

Cheers,
Gary