From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15531 invoked by alias); 7 Apr 2008 19:06:21 -0000 Received: (qmail 15521 invoked by uid 22791); 7 Apr 2008 19:06:19 -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; Mon, 07 Apr 2008 19:06:01 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 0F7703C0C7; Mon, 7 Apr 2008 12:06:00 -0700 (PDT) Subject: Re: Strangeness in set command From: Michael Snyder To: Daniel Jacobowitz Cc: Eli Zaretskii , Andreas Schwab , gdb@sources.redhat.com In-Reply-To: <20080405185423.GB13805@caradoc.them.org> References: <20080405185423.GB13805@caradoc.them.org> Content-Type: text/plain Date: Mon, 07 Apr 2008 19:28:00 -0000 Message-Id: <1207595159.31772.330.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/msg00062.txt.bz2 On Sat, 2008-04-05 at 14:54 -0400, Daniel Jacobowitz wrote: > On Sat, Apr 05, 2008 at 08:12:43PM +0300, Eli Zaretskii wrote: > > Does anyone object to improving the error message to mention "set > > variable"? > > I don't think it will help; it's just luck you got an ambiguity since > there are two commands starting with s. You could get any number of > other errors, or even silent success. Like: > > (gdb) set ser.a = 1 > Undefined set serial command: ".a = 1". Try "help set serial". > (gdb) set args.a = 1 > (gdb) show args > Argument list to give program being debugged when it is started is ".a = 1". I think the way to think about this is that the real command is "set variable", and that "set " has been allowed as a shortcut command so long as the argument is not ambiguous with another "set" command. 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.