bug#25025: python-shell-calculate-command is wrong

[Clément Pit--Claudel]

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