From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5810 invoked by alias); 8 Apr 2008 20:45:44 -0000 Received: (qmail 5801 invoked by uid 22791); 8 Apr 2008 20:45:44 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Apr 2008 20:45:26 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 496683BC36; Tue, 8 Apr 2008 13:45:24 -0700 (PDT) Subject: Re: Strangeness in set command From: Michael Snyder To: Andrew STUBBS Cc: Eli Zaretskii , drow@false.org, schwab@suse.de, gdb@sources.redhat.com In-Reply-To: <47FB4FAA.9000107@st.com> References: <20080405185423.GB13805@caradoc.them.org> <1207595159.31772.330.camel@localhost.localdomain> <47FB4FAA.9000107@st.com> Content-Type: text/plain Date: Wed, 09 Apr 2008 00:44:00 -0000 Message-Id: <1207687523.31772.393.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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: 2008-04/txt/msg00070.txt.bz2 On Tue, 2008-04-08 at 11:57 +0100, Andrew STUBBS wrote: > Eli Zaretskii wrote: > >> From: Michael Snyder > >> Cc: Eli Zaretskii , Andreas Schwab , gdb@sources.redhat.com > >> Date: Mon, 07 Apr 2008 12:05:59 -0700 > >> > >> The problem is that "so long as it is not ambiguous" > >> is dicy, and changes over time as we add new subcommands > >> to "set". > >> > >> The shortcut is probably one of those "seemed like a > >> good idea at the time" things, but now it's established > >> and we're stuck with it. > >> > >> It would probably be a good idea if, every time we parse > >> a "set" command, we try to match it with BOTH a variable > >> AND a subcommand, and if there is ambiguity we say so > >> explicitly. > > > > Or maybe, if the text after "set " has a `=' character in it, we > > should ask whether the user really meant "set variable". IOW, refuse > > to obey this shortcut, even if it's unambiguous. > > > > Hmmm, that's not great for set args: > > (gdb) set args --command=myscript Well, ok, you could parse the first token (in this case "args"), and then look for an = following it. But you could have expressions where the assignment operator wouldn't be the first token, eg: set ax->by = 12 or set *pc = 42 While not dismissing this idea, what about my first proposal of parsing the args first as an expression, and second as a subcommand, and issuing an error if both parses succeed?