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.