From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20007 invoked by alias); 21 Jul 2009 06:13:55 -0000 Received: (qmail 19998 invoked by uid 22791); 21 Jul 2009 06:13:54 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jul 2009 06:13:48 +0000 Received: from totara (154.28.255.123.dynamic.snap.net.nz [123.255.28.154]) by viper.snap.net.nz (Postfix) with ESMTP id 16EB73DA448; Tue, 21 Jul 2009 18:13:45 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id BEA46C15A; Tue, 21 Jul 2009 18:13:43 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19045.23703.743876.775308@totara.tehura.co.nz> Date: Tue, 21 Jul 2009 06:13:00 -0000 To: "Marc Khouzam" Cc: Subject: Re: [RFC] Queries and frontends In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA07C00023@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA07C00023@ecamlmw720.eamcs.ericsson.se> From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes 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 X-SW-Source: 2009-07/txt/msg00153.txt.bz2 > First, let's mention the "set confirm off" command. The documentation > at section 20.7 reads: > "If you are willing to unflinchingly face the consequences of your own > commands, you can disable this "feature":" > > So, from the doc and from what seems (to me :-)) like the proper > behavior, when we "set confirm off", all commands that use a query > should simply be performed without asking the user. > > The current implementation of queries does not do that. Instead, > it will follow the default answer of a query. Such a default answer > makes sense when trying to guide the user in a choice, but when > "set confirm off" we should really let the command execute. The behaviour is as I would expect from the documentation. > As an example, setting pending breakpoints has a default answer of 'n'. > What that means (unless I'm wrong) is that with "set confirm off", > pending breakpoints will NOT be set. > > The patch below changes defaulted_query() to always answer "yes" if > 'confirm' is off. I would find this behaviour confusing. In any case, the "set confirm off" command is for interactive use, not front ends. Here's a revised patch for my original request. It doesn't help with issues relating to GDB/MI but just uses the "server prefix" instead of a special option. I have used this trick previously (2007-07-10) to avoid setting the convenience variable $_ with breakpoints. This seems appropriate as I think the "server" command was created many years ago by Tom Lord or Jim Kingdon for use with annotations. I could add a suitable note to the documentation. -- Nick http://www.inet.net.nz/~nickrob 2009-07-21 Nick Roberts * record.c (cmd_record_stop): Don't ask for confirmation if server prefix is used. *** record.c.~1.8.~ 2009-07-21 17:58:01.000000000 +1200 --- record.c 2009-07-21 18:02:30.000000000 +1200 *************** *** 24,29 **** --- 24,30 ---- #include "event-top.h" #include "exceptions.h" #include "record.h" + #include "top.h" #include *************** cmd_record_stop (char *args, int from_tt *** 1157,1164 **** { if (current_target.to_stratum == record_stratum) { ! if (!record_list || !from_tty || query (_("Delete recorded log and " ! "stop recording?"))) unpush_target (&record_ops); } else --- 1158,1165 ---- { if (current_target.to_stratum == record_stratum) { ! if (!record_list || !from_tty || server_command ! || query (_("Delete recorded log and stop recording?"))) unpush_target (&record_ops); } else