Re: [PATCH] Indicate batch mode failures by exiting with nonzero status

[Gary Benson <gbenson at redhat dot com>]

Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
> 
> Gary> +/* Did the last invocation of catch_command_errors throw an error?  */
> Gary> +
> Gary> +static bool last_command_failed = false;
> 
> catch_command_errors seems to return a boolean, so I think a global
> shouldn't be necessary.

True.  It was a hang up from a previous version of the patch.
I can change it.

> Also, why just the last command?  I mean, I guess I don't really know
> what I would expect, but maybe if any command failed, gdb should exit?

That was my thinking, to have GDB exit 1 on the first error in batch
mode, but people objected; see the followups to:

  https://sourceware.org/ml/gdb/2018-07/msg00009.html

The last command thing was something that Pedro wanted.  The patch
would originally exit 1 if _any_ error occurred, but Pedro reasoned
that the last operation is the thing you wanted to happen and earlier
failures might be spurious, e.g. bad commands in gdbinit files.
Though you have situations like:

  bash$ gdb -batch -p 12345 -ex "info sharedlibrary"
  ptrace: No such process.
  No shared libraries loaded at this time.
  bash$ echo $?
  0

> Right now there seems to be a discrepancy where if you do "gdb -ex
> fail -ex fail -ex fail", each one will be run; but if you put the
> commands into a file and "gdb -x file", then only the first one will
> be run.  I'm not sure if this is good or bad.

Yeah, it's inconsistent and I hate it :/

I wonder if people would accept me changing the default behaviour to
exit 1 on the first error, with an option e.g. -batch-ignore-errors
to revert to the current behaviour.  I might reply to the original
thread suggesting that.

> I suppose one nice thing about the "last command only" approach is
> that you could ignore failures by tacking on one more -ex with some
> sort of no-op.

Every cloud has a silver lining :)

Cheers,
Gary