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

[Noam Postavsky]

On Fri, Dec 2, 2016 at 10:46 AM, Eli Zaretskii <eliz@gnu.org> 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ément Pit--Claudel
<clement.pit@gmail.com> 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é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?

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=20744#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 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.

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 
> function, probably based on eshell.
>
> Cheers,
> Clément.
>