From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13250 invoked by alias); 22 Feb 2006 14:29:57 -0000 Received: (qmail 13236 invoked by uid 22791); 22 Feb 2006 14:29:57 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 22 Feb 2006 14:29:56 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBv05-0005dB-O1; Wed, 22 Feb 2006 09:29:53 -0500 Date: Wed, 22 Feb 2006 18:01:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sourceware.org Subject: Re: Quoting, backslashes, CLI and MI Message-ID: <20060222142953.GA20393@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sourceware.org References: <20060221213324.GA30729@nevyn.them.org> <8f2776cb0602212223p1b8fda93meb9b12e5d187b3b6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0602212223p1b8fda93meb9b12e5d187b3b6@mail.gmail.com> User-Agent: Mutt/1.5.8i 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/msg00292.txt.bz2 On Tue, Feb 21, 2006 at 10:23:38PM -0800, Jim Blandy wrote: > How does buildargv-style quoting interact with commands that take > expressions as arguments? Aren't there 'set' commands that do this? Oof. That's a good question. Yes, there are. var_string, var_string_noescape, var_optional_filename, and var_filename all take literal text. So do var_boolean, var_auto_boolean, and var_enum. var_integer, var_zinteger, and var_uinteger all take expressions. 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. For MI it's messier... there's an obvious way in which MI clients can quote expressions using double quotes, and it would be nice if they did so. But read on. Of the 133 MI commands listed in mi-cmds.c, 53 have an MI implementation and use the MI parser; 4 have a CLI implementation but take no arguments; 64 are unimplemented; and 12 pass straight through to CLI commands with arguments. That's a gratifyingly small number, I was afraid it would be much worse. They are: -break-after -break-condition -break-delete -break-disable -break-enable -break-info -exec-arguments -file-exec-and-symbols -file-exec-file -file-symbol-file -gdb-set -gdb-show So, some quoting issues there. For MI, the -gdb-set example in the manual is very unfortunate: -gdb-set $foo=3 And I know that Eclipse will issue: -gdb-set auto-solib-add 0 What I am considering at the moment is adjusting mi3 to support only the second form, i.e. for GDB configuration variables. Then the syntax would be: -gdb-set IDENTIFIER [IDENTIFIER...] VALUE After all, you can always use -data-evaluate-expression to accomplish the other meaning. Again, this is an incompatible change and would have to be done only for mi3. Does it sound like a good idea? Bad idea? 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! -- Daniel Jacobowitz CodeSourcery