[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25025: python-shell-calculate-command is wrong
From: |
Clément Pit--Claudel |
Subject: |
bug#25025: python-shell-calculate-command is wrong |
Date: |
Fri, 2 Dec 2016 11:15:16 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
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ément, 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?
As far as I understand we have two conflicting requirements:
* One part of the code wants access to switches passed to python, as a list 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 know
which switches are being passed can use the possibly-incorrect
split-string-and-unquote to split user-supplied strings, but the user-supplied
command is run as-is through a shell.
2. Keep running python as a subprocess, without a shell; in that case,
user-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.
In the long run, it would be nice to offer a read-shell-command-as-list
function, probably based on eshell.
Cheers,
Clément.
signature.asc
Description: OpenPGP digital signature