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: Eli Zaretskii
Subject: bug#25025: python-shell-calculate-command is wrong
Date: Wed, 30 Nov 2016 17:55:17 +0200

> From: address@hidden
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Tue, 29 Nov 2016 20:56:16 -0500
> 
> Clément Pit--Claudel <address@hidden> writes:
> 
> > On 2016-11-29 19:36, address@hidden wrote:
> >> Eli Zaretskii <address@hidden> writes:
> >> 
> >>>> From: address@hidden
> >>>> Cc: address@hidden,  address@hidden
> >>>> 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

Confused: how does python-shell-completion-native-disabled-interpreters
get into this picture?  The function which uses it,
python-shell-completion-native-interpreter-disabled-p, looks at
python-shell-interpreter, which isn't affected by quoting or by how
the command is treated.  What am I missing?





reply via email to

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