From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Fixing Windows and DOS command line argument quoting Date: Mon, 25 Apr 2011 01:49:29 -0700 Message-ID: <4DB53599.8040703@gmail.com> References: <4DB4D7DB.50101@gmail.com> <83y62yal3o.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig521AA5891FAFC8C53AFF96FC" X-Trace: dough.gmane.org 1303721386 657 80.91.229.12 (25 Apr 2011 08:49:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2011 08:49:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 10:49:42 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QEHUD-0004Lo-LV for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 10:49:41 +0200 Original-Received: from localhost ([::1]:48582 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEHUC-0000ci-Uw for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 04:49:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEHUA-0000cN-BK for emacs-devel@gnu.org; Mon, 25 Apr 2011 04:49:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEHU9-0005cy-HQ for emacs-devel@gnu.org; Mon, 25 Apr 2011 04:49:38 -0400 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:37953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEHU7-0005bp-Tt; Mon, 25 Apr 2011 04:49:36 -0400 Original-Received: by pvc12 with SMTP id 12so1350243pvc.0 for ; Mon, 25 Apr 2011 01:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type; bh=lIcHzp+9pJxqvpHl5P7qz+gzjJ5s+1Sc4fZ3Vabmj4k=; b=R8WsH1JGmaf9/iTiVHIcR+eKJYBs6qRbBTvcR1I/LMdxXaFa7qmM9JB4rMQH7sJWaF yxtLOudcP47MUsoK+q2Va3NQ3evi9TAm5Mb3NgW+FWOYrdcOU4sP3YZTlU+Zsd8Qd8AP PbKnWm2m3D4DbX8Ez1eaCyL/BNKlI6KDVYA58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=Q8phN7tVVVcDRfGdZi/XciPLQeXdF1ayFCxfKolartvdW7sKEF0cx/Y065gLKc+MLG 6FRVI2rf8VBqtjD11BsHAEqpeDMmKsyoN2q0ALC+kR4HZK4kL+ItiqCBZSDO4Iqz/eHL XAO3e/p+TrdeQ4kZB49j4vobrh8w86XgV/pEc= Original-Received: by 10.68.1.137 with SMTP id 9mr5951970pbm.475.1303721374462; Mon, 25 Apr 2011 01:49:34 -0700 (PDT) Original-Received: from [192.168.1.2] (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id d3sm3776568pbh.73.2011.04.25.01.49.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 01:49:33 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <83y62yal3o.fsf@gnu.org> X-Enigmail-Version: 1.1.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.83.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138708 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig521AA5891FAFC8C53AFF96FC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eli, Thanks for taking a look at the patch. On 4/24/11 11:41 PM, Eli Zaretskii wrote: > Thanks. I have 2 requests and a question. The requests are: >=20 > . Please leave the `ms-dos' quoting as it was before. (Your research > and blog are not valid for the MS-DOS, a.k.a. DJGPP, build of > Emacs, which uses its own private way of passing and decoding > command lines, bypassing MS runtime and OS facilities. The > problems you mention in your blog do not exist in the MS-DOS > build.) Please make the new quoting method effective for the > `windows-nt' case alone. What happens when MS-DOS Emacs executes a non-DJGPP program? Doesn't it ever pass arguments through the command interpreter? It's been a very long time since I've used MS-DOS, and I don't know its command interpreter's behavior differs from that of NT's cmd.exe. > . Please install this only on the trunk. The emacs-23 branch should > not be destabilized by such experiments at this time. Fair enough. > My question is this: will cmdproxy need any changes to support this > new kind of quoting, or does it already have everything that it needs? Thanks for bringing up cmdproxy --- I hadn't considered its presence, and for now, it's a fly in the ointment. For concision, let's denote the CreateProcess/CommandLineToArgvW quoting "level one quoting" and the requisite munging cmd.exe "level two quoting". w32proc.c already performs level one quoting, which is sufficient because w32proc uses CreateProcess directly. To execute a shell command with an argument Foo, we level-one-quote and level-two-quote Foo, then run cmdproxy with Foo as an argument, allowing w32proc to level-one-quote it (again). cmdproxy (or more precisely, the C runtime to which it's linked) level-one-dequotes the value supplied with the /c option and runs the command interpreter, supplying that argument as its command line. The command interpreter level-two-dequotes this command line, sending the result to the indicated child program, which level-one-dequotes it and receives exactly Foo. This process would work well, except that cmdproxy contains an optimization that causes it to bypass the command interpreter entirely when the supplied command line doesn't appear to contain any shell metacharacters. In this case, cmdproxy passes the supplied command, which is still level-two-quoted, directly to CreateProcess, causing the child to attempt to level-one-dequote a level-two-quoted string, likely yielding unexpected results. Because shell-quote-argument doesn't know whether its return value will be interpreted by cmd or by CreateProcess alone, we can't solve the problem there. Two solutions remain: 1. we can have cmdproxy level-two-dequote the supplied command line before giving it to CreateProcess, or 2. we can remove optimization described above and have cmdproxy always run the command interpreter. I favor the second option: cmd starts very quickly, and we don't save much time by bypassing it. Adding level-two-dequoting to cmdproxy would add additional complexity and duplicate logic already present in cmd itself. Also, the current strategy for deciding whether to run a command directly or execute it via the shell doesn't sit right with me, as it make the wrong decision when arguments happen to contain quoted shell metacharacters. Thanks again, Daniel Colascione --------------enig521AA5891FAFC8C53AFF96FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk21NZsACgkQ17c2LVA10VuVXwCguYnJbXeR6zMVl4mXjqtihSni XZAAoKZ2qPNo/IQzhugP8yuPMfb5rEQ3 =JTud -----END PGP SIGNATURE----- --------------enig521AA5891FAFC8C53AFF96FC--