See below for a first pass version of PEP 568, which builds on PEP 567
to add context isolation for generators. Basically, as far as features
go:
PEP 567 + PEP 568 = PEP 550
The actual API details are all different though.
To reiterate, *this is not currently a proposal for adding to Python*.
On Sun, Jan 7, 2018, at 19:50, Steve Dower wrote:
> Considering there is no cross-platform compatibility here anyway, I
> don’t think it’s that bad an option to let users do their own escaping,
> especially since those who are successfully using this feature already
> do.
I don't really think w
Quoting the /c and /k values to cmd.exe is... complicated, to say the least. I
struggle to get it right for a single example, let alone generalising it. The
/s option also has an impact – sometimes it helps you avoid double-escaping
everything, but not always.
Writing complex shell=True command
Ok, then I'm happy to improve the escaping!
I was confused because I could not understand that nobody than me should
have run into this problem before.
There are many special cases. I'll try my very best :)
Cheers -- Chris
On 07.01.18 21:59, Guido van Rossum wrote:
> On Sun, Jan 7, 2018 at 12:3
On Sun, Jan 7, 2018 at 12:30 PM, Gregory P. Smith wrote:
> the best way to improve shell escaping on windows is to send a PR against
> the list2cmdline code that escapes everything you believe it should when
> running on windows. With hyperlinks to the relevant msdn info about what
> might need e
the best way to improve shell escaping on windows is to send a PR against
the list2cmdline code that escapes everything you believe it should when
running on windows. With hyperlinks to the relevant msdn info about what
might need escaping.
On Sun, Jan 7, 2018 at 11:38 AM Christian Tismer
wrote:
Ok, I thought only about Windows where people often use shell=True.
I did not see that as a Linux problem, too.
Not meant as a proposal, just loud thinking... :-)
But as said, the incomplete escaping is a complete mess.
Ciao -- Chris
On 07.01.18 19:54, Christian Tismer wrote:
> By "normal user
By "normal user expectations" I meant the behavior when the builtin commands
were normal programs.
Using "shell=True" is everywhere recommended to avoid, and I believe
we could avoid it by giving them replacements for build-ins.
But I don't care if the shell escaping is correct. And that is not
t
That is true.
list2cmdline escapes partially, but on NT and Windows10, the "^" must
also be escaped, but is not. The "|" pipe symbol must also be escaped
by "^", as many others as well.
The effect was that passing a rexexp as parameter to a windows program
gave me strange effects, and I recognized
On Sun, Jan 7, 2018 at 9:09 AM, Eric V. Smith wrote:
> On 1/3/2018 1:17 PM, Eric V. Smith wrote:
>
>> I’ll open an issue after I have time to read this thread and comment on
>> it.
>>
>
> https://bugs.python.org/issue32513
> I need to think though how __eq__ and __ne__ work, as well as the orderi
On Sun, Jan 7, 2018 at 8:17 AM, Christian Tismer
wrote:
> As a side note: In most cases where shell=True is found, people
> seem to need evaluation of the PATH variable. To my understanding,
>
> >>> from subprocess import call
> >>> call(("ls",))
>
> works in Linux, but (with dir) not in Windows.
I assume you're talking about list2cmdline()? That seems to be used to
construct a string that can be passed to `cmd /c "{}"` -- it gets
substituted instead of the {}, i.e. surrounded by ". I honestly can't say I
follow that code completely, but I see that it escapes double quotes. Why
is there a n
On 1/3/2018 1:17 PM, Eric V. Smith wrote:
I’ll open an issue after I have time to read this thread and comment on it.
https://bugs.python.org/issue32513
I need to think though how __eq__ and __ne__ work, as well as the
ordering operators.
My specific concern with __ne__ is that there's one f
Hi Guys,
yes I know there was a lengthy thread on python-dev in 2014
called "subprocess shell=True on Windows doesn't escape ^ character".
But in the end, I still don't understand why subprocess does
escape the double quote when shell=True but not other special
characters like "^"?
Yes I know th
14 matches
Mail list logo
