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

[Pedro Alves <palves@redhat.com>]

On 08/17/2018 11:59 AM, Gary Benson wrote:
> 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.

s/wanted/suggested investigating/.

> 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.

Right, and given that, I recalled how TCL handles the return code of
procedures that don't have an explicit return, which is that the return
code of the last command counts.  So I thought that approach was
worth investigating.

> 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

As long as GDB runs _both_ commands, I think the "exit status is
determined by success/failure of last command run" rule is better.

Making GDB exit immediately on first error (and thus not run
"info sharedlibrary" in that case) might be worth pursuing as well,
maybe with a new command line option, but it seems orthogonal to
the exit code rules.

> 
>> 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 think it depends on perspective.  If you put "fail" in a file, and then
do "gdb -x file -x file -x file", then "fail" is tried 3 times as well:

$ gdb -x file -x file -x file
[...]
file:1: Error in sourced command file:
Undefined command: "fail".  Try "help".
file:1: Error in sourced command file:
Undefined command: "fail".  Try "help".
file:1: Error in sourced command file:
Undefined command: "fail".  Try "help".
(gdb) 

> 
> 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.

If we went that route, I'd think that could be a separate orthogonal
option.  I.e., a "stop/continue processing commands on first error"
option.  That could be used even without -batch.

That would be something in the same spirit of the new
"thread apply" / "frame apply" flags:

  FLAG arguments are -q (quiet), -c (continue), -s (silent).

> 
>> 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 :)
> 
Thanks,
Pedro Alves