From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7409 invoked by alias); 17 Aug 2018 15:23:50 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7398 invoked by uid 89); 17 Aug 2018 15:23:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2002, responding X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Aug 2018 15:23:48 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1AA0D814FDCE; Fri, 17 Aug 2018 15:23:47 +0000 (UTC) Received: from blade.nx (ovpn-117-165.ams2.redhat.com [10.36.117.165]) by smtp.corp.redhat.com (Postfix) with ESMTP id CC6EE2156712; Fri, 17 Aug 2018 15:23:46 +0000 (UTC) Received: by blade.nx (Postfix, from userid 1000) id 349F080AFCC4; Fri, 17 Aug 2018 16:23:46 +0100 (BST) Date: Fri, 17 Aug 2018 15:23:00 -0000 From: Gary Benson To: Paul Smith Cc: Ruslan Kabatsayev , gdb@sourceware.org Subject: Re: gdb -batch always exits with status 0 Message-ID: <20180817152345.GA2920@blade.nx> References: <20180705144659.GA29169@blade.nx> <2c7ad73e90cc7417bd23b4529261d8c737668571.camel@gnu.org> <20180817110354.GB32726@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00036.txt.bz2 Paul Smith wrote: > On Fri, 2018-08-17 at 12:03 +0100, Gary Benson wrote: > > Paul, Ruslan, would it be acceptable to you if I: > > > > 1) changed the default behaviour to exit 1 on the first error > > 2) added an option (e.g. -ignore-errors) to revert to the current > > behaviour. > > [I'm on vacation until next week so may not be responding immediately] > > Well it would not be ideal as I'd need to go through all my scripts > etc. and modify them to add an extra argument. How much work would this be for you? Minutes, hours, days, weeks? > I guess I'm not really sure why we want to change the default > behavior here. Do we have people requesting this change? I haven't > seen a groundswell of people saying they were confused becuase they > expected a different behavior, and the current behavior has good and > useful reasons for existing (i.e., not just an oversight). There isn't a groundswell of people, no. I started investigating an orthoganal issue, that the manual says GDB in batch mode exits with nonzero status to indicate error, but in reality GDB always exits with status 0. It should be a trivial fix, except that the way GDB continues past errors makes it difficult to implement--exit nonzero for any error, or the last error, or only some errors... which? Also, exactly which statements get executed if errors occur isn't exactly consistent. And all that disappears when you say, ok, lets just exit nonzero at the first error, which is what I'd intuitively expected would happen. > Wouldn't the most sensible/least impactful way forward be to leave > the current behavior as-is, and then if people want a different > behavior add a new option they can use to request it? 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. Cheers, Gary