Re: gdb -batch always exits with status 0

[Pedro Alves <palves at redhat dot com>]

On 08/17/2018 05:03 PM, Gary Benson wrote:
> Ruslan Kabatsayev wrote:
>> On Fri, 17 Aug 2018 at 18:23, Gary Benson <gbenson@redhat.com> wrote:
>>>
>>> It would be the least impactful way, sure, but my point is that
>>> GDB doesn't operate in an intuitive way, and my view is that
>>> whatever is intuitive should be the default.  Having to request it
>>> with a special flag makes GDB harder for new users.
>>
>> Not sure about intuitiveness of early exit, but we have an example
>> of the converse: bash (and other shells). Namely, by default it
>> executes all the commands, exits with the exit status of the last
>> command executed. But you can `set -e`, and then first failing
>> command will stop processing. But then, there do exist means to
>> suppress failure (e.g. `badCommand && true`), which GDB doesn't seem
>> to have.
> 
> Shells are the only example I could think of.  And I wonder what
> proportion of shell scripts start with 'set -e' :)  Having to add
> that is the kind of thing I mean about making things harder for
> new users.

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.

Thanks,
Pedro Alves