From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32296 invoked by alias); 7 Apr 2008 11:34:39 -0000 Received: (qmail 32286 invoked by uid 22791); 7 Apr 2008 11:34:38 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog16.obsmtp.com (HELO s200aog16.obsmtp.com) (207.126.144.130) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Apr 2008 11:34:16 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Mon, 07 Apr 2008 11:34:05 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 54E3ADAEC; Mon, 7 Apr 2008 11:33:45 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0AC334C2D1; Mon, 7 Apr 2008 11:33:44 +0000 (GMT) Received: from [164.129.12.194] (bri0669.bri.st.com [164.129.12.194]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CJY67615 (AUTH stubbsa); Mon, 7 Apr 2008 12:32:51 +0100 (BST) Message-ID: <47FA0698.3060009@st.com> Date: Mon, 07 Apr 2008 18:32:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eli Zaretskii , Andreas Schwab , gdb@sources.redhat.com Subject: Re: Strangeness in set command References: <20080405185423.GB13805@caradoc.them.org> In-Reply-To: <20080405185423.GB13805@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00058.txt.bz2 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". This has been bugging me for some time. Not just for interactive use, but also because it's quite easy to write scripts which work now, but might fail unexpectedly in future versions of GDB. E.g. (gdb) set index = 1 There's no GDB command "set index", so this sets a program variable, which is probably what the user intended. However, can you say for sure GDB will never use this name? It's exactly the sort of useful name that would find a use, and when it does a script with this command will go wrong. Perhaps the best solution would be to print an expanded version, thus making it explicit what is going on. E.g. (gdb) set ser.a = 1 => set serial .a = 1 Undefined set serial command: ".a = 1". Try "help set serial". (gdb) set args.a = 1 => set args .a = 1 (gdb) show args Argument list to give program being debugged when it is started is ".a = 1". (gdb) set index = 1 => set variable index = 1 I wouldn't recommend printing the command when no expansion is performed - that would really annoy me, especially when sourcing scripts - but I would suggest extending the feature to commands in scripts. Scripts could be silenced simply by making them explicit. This would encourage people to future proof their scripts. Naturally, there would have to be a way to make the messages go away. Just a thought Andrew