bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: npostavs
Subject: bug#25025: python-shell-calculate-command is wrong
Date: Tue, 29 Nov 2016 20:56:16 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-11-29 19:36, npostavs@users.sourceforge.net wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> From: npostavs@users.sourceforge.net
>>>> Cc: 25025@debbugs.gnu.org,  clement.pit@gmail.com
>>>> Date: Sun, 27 Nov 2016 11:06:03 -0500
>>>>
>>>>> Why does it need to be split?  A shell command can (even should) be
>>>>> handed to the shell as a single string.
>>>>
>>>> Currently it's not a shell command, because a shell isn't being used.
>>>> My other suggestion was to use a shell:
>>>>
>>>>>> It might be more intuitive to actually use a shell and then the user
>>>>>> would enter a shell command (though inserting a shell into things
>>>>>> might bring more complications).
>>>
>>> If it doesn't use a shell, then it has no business quoting commands or
>>> their parts using shell-related APIs.
>>>
>>> So yes, I think using a shell would be TRT here.  Can someone please
>>> work on a patch in that direction?  This problem exists for a long
>>> time, so I hope we could solve it soon.
>> 
>> Hmm, the difficulty in using a shell is that the current code wants to
>> parse the command into interpreter and arguments in order to match
>> against `python-shell-completion-native-disabled-interpreters'.
>
> That doesn't prevent us from using a shell.  We run the command
> unmodified through a shell, and we split it and analyze it separately
> to decide whether to enable completion.  But we don't split and
> reassemble it before running it.

Yes, but then we need to parse a shell quoted command, which is quite a
bit more difficult.  That gets back to your suggestion about getting an
elisp equivalent to shlex I suppose.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25025#28





reply via email to

[Prev in Thread] Current Thread [Next in Thread]