From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3661 invoked by alias); 3 Dec 2015 11:54:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3634 invoked by uid 89); 3 Dec 2015 11:54:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 03 Dec 2015 11:54:39 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 21DE4C0CC62E; Thu, 3 Dec 2015 11:54:37 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB3BsZ3G000595; Thu, 3 Dec 2015 06:54:36 -0500 Message-ID: <56602D7B.2010404@redhat.com> Date: Thu, 03 Dec 2015 11:54:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Cross , gdb-patches@sourceware.org CC: gdb@sourceware.org Subject: Re: Always run GDB command post-hook after pre-hook has been run References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00042.txt.bz2 On 12/02/2015 06:24 PM, Stephen Cross wrote: > I was wondering if anyone has had a chance to look at this patch? > (I've also CC'ed the gdb list since I'm looking for input on the > approach.) Implementation approach, or on the idea in the first place? I think it'd help if you told us the motivation. What's the intent of running the hookpost even on error? What are you trying to use the hooks for? >> As you can see the post-hook is now always being called, even if the >> command fails. At first blush, it looks reasonable. But as always, the devil's in the details. I think only defining what happens around the corner cases can we be sure. Playing devil's advocate, isn't it reasonable to say that existing hookpost scripts out there may be assuming that they only run if the hooked command finished successfully? Curiously, the existing documentation actually has a related comment: > @cindex hooks, post-command > @kindex hookpost > A hook may also be defined which is run after the command you executed. > Whenever you run the command @samp{foo}, if the user-defined command > @samp{hookpost-foo} exists, it is executed (with no arguments) after > that command. Post-execution hooks may exist simultaneously with > pre-execution hooks, for the same command. > > It is valid for a hook to call the command which it hooks. If this > occurs, the hook is not re-executed, thereby avoiding infinite recursion. > > @c It would be nice if hookpost could be passed a parameter indicating > @c if the command it hooks executed properly or not. FIXME! Wonder whether we should have that. Alternatively, guess we could have a new hookerror hook, that would run on error instead of hookpost. What happens / should happen if the hookpost itself throws an error? Do we lose the original hooked-command's error? Is that OK? Thanks, Pedro Alves