From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15631 invoked by alias); 22 Feb 2006 19:50:37 -0000 Received: (qmail 15622 invoked by uid 22791); 22 Feb 2006 19:50:36 -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 19:50:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FC00O-00088z-SP; Wed, 22 Feb 2006 14:50:32 -0500 Date: Wed, 22 Feb 2006 19:53:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sourceware.org, jimb@red-bean.com Subject: Re: Quoting, backslashes, CLI and MI Message-ID: <20060222195032.GC30642@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sourceware.org, jimb@red-bean.com References: <20060221213324.GA30729@nevyn.them.org> <8f2776cb0602212223p1b8fda93meb9b12e5d187b3b6@mail.gmail.com> <20060222142953.GA20393@nevyn.them.org> <8f2776cb0602220939i5189212ds8fb249747851cf72@mail.gmail.com> <20060222180137.GA27535@nevyn.them.org> <20060221213324.GA30729@nevyn.them.org> <8f2776cb0602212223p1b8fda93meb9b12e5d187b3b6@mail.gmail.com> <20060222142953.GA20393@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00307.txt.bz2 Hi Eli, I think I haven't explained the issue with -exec-arguments very clearly, since your two responses are contradictory. I agree with one of them :-) Let me try to straighten it out. On Wed, Feb 22, 2006 at 09:26:14PM +0200, Eli Zaretskii wrote: > We should leave it alone, and not only because it's a mess: > "-exec-arguments" _should_ pass its argument to the shell, it should > not second-guess the shell features, nor reinvent them. [Second-guessing I certainly agree with, reinventing the shell features is a separate discussion which we've had elsewhere; but that's a different topic.] On Wed, Feb 22, 2006 at 09:29:15PM +0200, Eli Zaretskii wrote: > > 1. We want -exec-arguments to take MI-quoted individual arguments, > > which are then passed as argv elements to the program. > > > > 2. We want -exec-arguments to take a single MI-quoted argument, > > which is the value to set the argument string to, for the target > > and/or shell to handle however they deem appropriate. > > I think we should take (2). We shouldn't second-guess or reinvent > shell features. There's a good chance that the string is actually > coming from a user who typed it, in which case it will be in the form > we type at the shell's prompt. So it should go to the shell for > interpretation. I agre that we want #2. But this isn't the same as leaving it alone; #1 is actually closer to leaving things alone. Here's one example: -exec-arguments a b "c d" Today, the shell would be invoked with this string: PROGRAMNAME a b "c d" Eventually the program would be invoked with three arguments: a, b, c d. In #1, the same thing would happen. In #2, this would be a syntax error. Here's another example: -exec-arguments "\"" Today, the shell would be invoked with "\"", which would eventually reach the program as a single double quote in the first argument. In #1 the same thing would happen. In #2 the shell would probably complain - it would be run as: PROGRAMNAME " Here's another example to consider: -exec-arguments "\n" Today this would run the shell with the command: PROGRAMNAME "\n" Depends on your shell, but generally speaking, you ought to get a backslash and an 'n' in the first argument. But #1 is going to pass a newline! And so would #2. And this one: -exec-arguments "\n" "\n" Today, two backslash-followed-by-n arguments. #1, two newline arguments. #2, syntax error. The advantage of #2 is that we have a well defined way to put any characters at all into the string using MI. Everything gets escaped twice: once by the MI layer and once by the shell. We document that, and everyone can deal with it robustly. > > So CLI "set args" will need to continue being unescaped, one way or > > another. > > Yes, and I Think this is The Right Thing to do, for the same reasons. I agree that this is the right thing to do (though a little tricky). -- Daniel Jacobowitz CodeSourcery