From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#25025: python-shell-calculate-command is wrong Date: Fri, 2 Dec 2016 11:41:54 -0500 Message-ID: References: <83polk3qow.fsf@gnu.org> <83inra13r3.fsf@gnu.org> <8337ic29y0.fsf@gnu.org> <87r35wj4b8.fsf@users.sourceforge.net> <83zikkzytf.fsf@gnu.org> <8737i9iz28.fsf@users.sourceforge.net> <1949fc46-fd26-dddb-86b2-ab3478587271@gmail.com> <87wpflhgsf.fsf@users.sourceforge.net> <83a8chq7x6.fsf@gnu.org> <83d1hbpobp.fsf@gnu.org> <87h96ngmmq.fsf@users.sourceforge.net> <83k2biokad.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480696992 20818 195.159.176.226 (2 Dec 2016 16:43:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 16:43:12 +0000 (UTC) Cc: 25025@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 02 17:43:08 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCqvT-0004Kx-9Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Dec 2016 17:43:07 +0100 Original-Received: from localhost ([::1]:35501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCqvX-0001VX-9x for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Dec 2016 11:43:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCqvR-0001VH-1B for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2016 11:43:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCqvN-0006pz-Sl for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2016 11:43:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35159) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCqvN-0006pm-OQ for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2016 11:43:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cCqvN-0001WZ-J5 for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2016 11:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Dec 2016 16:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 25025-submit@debbugs.gnu.org id=B25025.14806969225782 (code B ref 25025); Fri, 02 Dec 2016 16:43:01 +0000 Original-Received: (at 25025) by debbugs.gnu.org; 2 Dec 2016 16:42:02 +0000 Original-Received: from localhost ([127.0.0.1]:50558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCquQ-0001VB-Ix for submit@debbugs.gnu.org; Fri, 02 Dec 2016 11:42:02 -0500 Original-Received: from mail-oi0-f41.google.com ([209.85.218.41]:34080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCquO-0001Ug-GG for 25025@debbugs.gnu.org; Fri, 02 Dec 2016 11:42:00 -0500 Original-Received: by mail-oi0-f41.google.com with SMTP id y198so272456889oia.1 for <25025@debbugs.gnu.org>; Fri, 02 Dec 2016 08:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ca5XT6MKVyKi6Dz+djZOGEDAuZTa/PHNRFYtfMBfsJw=; b=SXKhhdATDlUO93/2qdKuJPM132T5KJu77G18x/E+HTDdvXwgl7m793bQJ2pGBnaH1i ZKF2rkr5mdItAfyU7YmMemME67BhTood5cd0+9n0eW6yT/3QYKkosz2PKonId71Htv7z H/uYhzjvAdW5bFtR2aE7oW4DwWM2+4+npfTz6BPpAXSdCWlnE48MI8tcFUNufvaHKosT aTz6+IAL/k65GRo9bIW8ky6hqJTVPMcdW+6/6QyYXrPHAlabc4jlHbXCAeV691WHo2pO ffonzZ7mn7KY8xiSB8vcstlE1MSAe9SNGOEsdpwPMk0lriqO1ZoUEnIqb5j5pE0q57cU yZSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=ca5XT6MKVyKi6Dz+djZOGEDAuZTa/PHNRFYtfMBfsJw=; b=SAQj9rbzOt80TRrmLXV/OVPDvh9d9eU7WI/mYI0aiPxnhk/0d+ZSRKuLlIOJvW6Gxh NG1bx1F2sIqhWdfd2RScpiM0KZ9McGTB17GPhV5HFDc0OS6NNe4b9FQTB/zfW0Ikxmg7 uLW8TxEZbhD712NU/0cAiuPoMenvULvQ0XYK3yF4ZoeWUNzL16sYLQ/ALRX/CCY3LTsY MCTfpsf5pEmUZIH+Zh832rMQuNR4QRktTrZxgROufKAk+DPanHbbhZm87HsrBVMBRxfk JlEatXTKaLPENsXpVqN9+dedMHtqsCU9ZLwiE+34V1rl0WJ0lMA8mKoUZQAr0iVU+Til fFcQ== X-Gm-Message-State: AKaTC03hrXwqFbrrdw8wDyO5awE3mElufqreyP35AFgsDd1H/7WuKV6pZQxyE0LD/S1eZaQNt8UawCZ5xGms/w== X-Received: by 10.157.53.50 with SMTP id o47mr23414136otc.19.1480696914650; Fri, 02 Dec 2016 08:41:54 -0800 (PST) Original-Received: by 10.157.6.234 with HTTP; Fri, 2 Dec 2016 08:41:54 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: G1HisMtz2cXQRd3e81_yMoP7tg8 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:126431 Archived-At: On Fri, Dec 2, 2016 at 10:46 AM, Eli Zaretskii wrote: > > Fine with me (and maybe also change the function's name while you are > at it). If you meant to remove the "shell" from `python-shell-calculate-command', I think that refers to the "python shell" (which would be called REPL in Lisp speak). There are quite a few other functions and variables with the python-shell prefix. On Fri, Dec 2, 2016 at 11:15 AM, Cl=C3=A9ment Pit--Claudel wrote: > On 2016-12-02 02:35, Eli Zaretskii wrote: >> Isn't combine-and-quote-strings wrong for quoting shell commands? >> AFAIR, it doesn't DTRT with some special characters that can appear in >> file names on Unix. Am I mistaken? >> >> But if my fears are unjustified, sure, why not? Cl=C3=A9ment, WDYT? > > On 2016-12-02 10:07, npostavs@users.sourceforge.net wrote: >> Okay, let me rephrase. `python-shell-calculate-command' currently >> generates a shell command, but none of its callers treat the result as a >> shell command (they don't pass it to a shell, they parse it with >> `split-string-and-unquote'). Therefore, the easiest fix is to change >> `python-shell-calculate-command' to no longer generate a shell command. >> >> The other possiblity is to change the callers to treat >> `python-shell-calculate-command's result as a shell command, but that >> looks more difficult (though it may be the better solution overall). > > Currently, run-python can read a shell command; do we want to remove this= feature? If not, then we do need a shell, don't we? It can "read" a shell command, but won't be able to *run* it unless it's parseable with split-string-and-unquote, so I don't think we're removing any feature here. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20744#53 > > As far as I understand we have two conflicting requirements: > > * One part of the code wants access to switches passed to python, as a li= st of switches. > * One part of the code wants to read a python command, including switches= , from the user. > > I'm not sure that we can get these two to both work in all cases, unless = we come up with a robust way to parse shell commands given by the user. I = see multiple solutions: > > 1. Use a shell to run python. Then the part of the code that wants to kno= w which switches are being passed can use the possibly-incorrect split-stri= ng-and-unquote to split user-supplied strings, but the user-supplied comman= d is run as-is through a shell. > > 2. Keep running python as a subprocess, without a shell; in that case, us= er-supplied commands (in C-u M-x run-python) need to be "parsed" back into = command + switches before running them, which introduces a small potential = for incorrect parsing. > > Noam, your approach is (2), right? I like the simplicity. Yes, my approach keeps the status quo, it just stops introducing shell-quoting which could be parsed incorrectly. > > In the long run, it would be nice to offer a read-shell-command-as-list f= unction, probably based on eshell. > > Cheers, > Cl=C3=A9ment. >