From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30628 invoked by alias); 22 Feb 2006 17:39:59 -0000 Received: (qmail 30620 invoked by uid 22791); 22 Feb 2006 17:39:59 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.192) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Feb 2006 17:39:58 +0000 Received: by xproxy.gmail.com with SMTP id t5so1091753wxc for ; Wed, 22 Feb 2006 09:39:56 -0800 (PST) Received: by 10.70.124.12 with SMTP id w12mr3868957wxc; Wed, 22 Feb 2006 09:39:55 -0800 (PST) Received: by 10.70.125.17 with HTTP; Wed, 22 Feb 2006 09:39:55 -0800 (PST) Message-ID: <8f2776cb0602220939i5189212ds8fb249747851cf72@mail.gmail.com> Date: Wed, 22 Feb 2006 18:05:00 -0000 From: "Jim Blandy" To: "Jim Blandy" , gdb@sourceware.org Subject: Re: Quoting, backslashes, CLI and MI In-Reply-To: <20060222142953.GA20393@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060221213324.GA30729@nevyn.them.org> <8f2776cb0602212223p1b8fda93meb9b12e5d187b3b6@mail.gmail.com> <20060222142953.GA20393@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00293.txt.bz2 On 2/22/06, Daniel Jacobowitz wrote: > In the CLI buildargv and the expression parser are clearly > incompatible; we'll have to use it only for non-expression > commands. Too many languages, et cetera. That's my feeling too. > So, some quoting issues there. For MI, the -gdb-set example in > the manual is very unfortunate: > > -gdb-set $foo=3D3 Yeah --- this seems to me to be taking an overloading of "set" designed to make life easier for humans and carrying it through to a machine interface, where it's not helpful, and where the ambiguity is problematic. I don't think this form of -gdb-set should be (or ever have been) supported. > Similar problems apply to the other listed MI commands. For instance, > -exec-arguments ARGS; should it take a single string which is then > split by buildargv into a vector, or should it take freeform text which > is then split into an argument vector? Well, right now it takes a > literal string, since it just passes the text to CLI "set args". > That's saved as a string and then passed to create_inferior as a > string, and eventually passed directly to a shell in the fork-child.c > case. So, as un-MI-like as it is, I think I'd have to leave this one > alone for now - it's just too big a can of worms! You'd have to rework a lot of code to make the quoting happen earlier.