On 11/06/2014 21:26, anatoly techtonik wrote:
I am banned from tracker, so I post the bug here:
The OP's approach to the Python community is beautifully summarised here
http://bugs.python.org/issue8940
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do
Paul Moore wrote:
Huh? CreateProcess uses PATH:
Hmm, in that case Microsoft's documentation
is lying, or subprocess is doing something itself
before passing the command name to CreateProcess.
Anyway, looks like there's no problem.
--
Greg
___
Python
On 15/06/2014 08:54, Paul Moore wrote:
On 15 June 2014 00:15, Greg Ewing wrote:
However, it says the Windows version uses CreateProcess, which
doesn't use PATH.
Huh? CreateProcess uses PATH:
Just to be precise:
CreateProcess *doesn't* use PATH if you pass an lpApplicationName
parameter. I
On 15 June 2014 00:15, Greg Ewing wrote:
> However, it says the Windows version uses CreateProcess, which
> doesn't use PATH.
Huh? CreateProcess uses PATH:
>py -3.4
Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600
64 bit (AMD64)] on win32
Type "help", "copyright", "credits"
On 15/06/2014 02:22, Ryan Gonzalez wrote:
Of course cmd.exe is hardcoded;
Of course it's not:
(from Lib/subprocess.py)
comspec = os.environ.get("COMSPEC", "cmd.exe")
I don't often expect, in these post-command.com days, to get anything
other than cmd.exe. But alternative command processors
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico mailto:ros...@gmail.com>> wrote:
> ISTM what you want is not shell=True, but a separate function that
> follows the system policy for translating a command name into a
> path-to-binary.
According to the docs, subprocess.Popen sh
Of course cmd.exe is hardcoded; there are no other shells on Windows! (I'm
purposely ignoring MinGW, Cygwin, command.com, etc.) If anything,
auto-escaping will break scripts that are already designed to escape carets
on Windows.
On Sat, Jun 14, 2014 at 2:54 PM, anatoly techtonik
wrote:
> On Fri
On Thu, Jun 12, 2014 at 5:12 AM, Chris Angelico wrote:
> On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
> > ISTM what you want is not shell=True, but a separate function that
> > follows the system policy for translating a command name into a
> > path-to-binary. That's something that, A
On Fri, Jun 13, 2014 at 5:11 AM, Nikolaus Rath wrote:
> "R. David Murray" writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly. It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why
On Fri, Jun 13, 2014 at 2:55 AM, Ryan Gonzalez wrote:
> SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be
> differences. If you really must:
>
> escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s
>
It is not about generic shell problem, it is about specific behavi
Florian Bruhin writes:
> * Nikolaus Rath [2014-06-12 19:11:07 -0700]:
>> "R. David Murray" writes:
>> > Also notice that using a list with shell=True is using the API
>> > incorrectly. It wouldn't even work on Linux, so that torpedoes
>> > the cross-platform concern already :)
>> >
>> > This k
On Fri, 13 Jun 2014 16:57:49 +1200, Greg Ewing
wrote:
> Nikolaus Rath wrote:
> > you almost certainly want to do
> >
> > Popen(['/bin/sh', 'for i in `seq 42`; do echo $i; done'], shell=False)
> >
> > because if your shell happens to be tcsh or cmd.exe, things are going to
> > break.
>
> On Uni
On 13/06/2014 03:11, Nikolaus Rath wrote:
> "R. David Murray" writes:
>> Also notice that using a list with shell=True is using the API
>> incorrectly. It wouldn't even work on Linux, so that torpedoes
>> the cross-platform concern already :)
>>
>> This kind of confusion is why I opened http://bu
Nikolaus Rath wrote:
you almost certainly want to do
Popen(['/bin/sh', 'for i in `seq 42`; do echo $i; done'], shell=False)
because if your shell happens to be tcsh or cmd.exe, things are going to
break.
On Unix, the C library's system() and popen() functions
always use /bin/sh, NOT the user'
* Nikolaus Rath [2014-06-12 19:11:07 -0700]:
> "R. David Murray" writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly. It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why I opened
On 13 Jun 2014 12:12, "Nikolaus Rath" wrote:
>
> "R. David Murray" writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly. It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why I opene
On Fri, Jun 13, 2014 at 12:11 PM, Nikolaus Rath wrote:
> Can someone describe an use case where shell=True actually makes sense
> at all?
>
> It seems to me that whenever you need a shell, the argument's that you
> pass to it will be shell specific. So instead of e.g.
>
> Popen('for i in `seq 42`;
"R. David Murray" writes:
> Also notice that using a list with shell=True is using the API
> incorrectly. It wouldn't even work on Linux, so that torpedoes
> the cross-platform concern already :)
>
> This kind of confusion is why I opened http://bugs.python.org/issue7839.
Can someone describe an
SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be
differences. If you really must:
escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s
Viola.
On Wed, Jun 11, 2014 at 5:53 PM, anatoly techtonik
wrote:
> On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
>
>
On 12 June 2014 05:34, Florian Bruhin wrote:
> Do the lookup in PATH yourself, it's not like that's rocket science.
Am I missing something here? I routinely do
subprocess.check_call(['hg', 'update']) or whatever, and it finds the
hg executable fine.
Paul
_
* anatoly techtonik [2014-06-12 02:00:55 +0300]:
> On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
>
> > Why pass shell=True when executing a single
> > command? I don't get it.
> >
>
> I don't know about Linux, but on Windows programs are not directly
> available as /usr/bin/python, so
On Wed, Jun 11, 2014 at 9:43 PM, Ethan Furman wrote:
> On 06/11/2014 07:12 PM, Chris Angelico wrote:
>>
>> On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
>>>
>>> ISTM what you want is not shell=True, but a separate function that
>>> follows the system policy for translating a command nam
On 06/11/2014 07:12 PM, Chris Angelico wrote:
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
ISTM what you want is not shell=True, but a separate function that
follows the system policy for translating a command name into a
path-to-binary. That's something that, AFAIK, doesn't currentl
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
> ISTM what you want is not shell=True, but a separate function that
> follows the system policy for translating a command name into a
> path-to-binary. That's something that, AFAIK, doesn't currently exist
> in the Python 2 stdlib, but Pytho
On Thu, Jun 12, 2014 at 10:00 AM, anatoly techtonik wrote:
> I thought exactly about that. Usually separate arguments are used to avoid
> problems with escaping of quotes and other stuff.
>
> I'd deprecate subprocess and split it into separate modules. One is about
> shell execution and another on
On Thu, Jun 12, 2014 at 2:00 AM, R. David Murray
wrote:
> Also notice that using a list with shell=True is using the API
> incorrectly. It wouldn't even work on Linux, so that torpedoes
> the cross-platform concern already :)
>
> This kind of confusion is why I opened http://bugs.python.org/issu
On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
> Why pass shell=True when executing a single
> command? I don't get it.
>
I don't know about Linux, but on Windows programs are not directly
available as /usr/bin/python, so you need to find command in PATH
directories. Passing shell=True m
On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
> On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote:
> > In all seriousness, to me this is obvious. When you pass a command to the
> > shell, naturally, certain details are shell-specific.
>
On Windows cmd.exe is used by default:
http://hg.python
Also notice that using a list with shell=True is using the API
incorrectly. It wouldn't even work on Linux, so that torpedoes
the cross-platform concern already :)
This kind of confusion is why I opened http://bugs.python.org/issue7839.
On Wed, 11 Jun 2014 16:58:30 -0500, Ryan wrote:
> Of cours
On Wed, Jun 11, 2014, at 13:26, anatoly techtonik wrote:
> I am banned from tracker, so I post the bug here:
Being banned from the tracker is not an invitation to use python-dev@ as
one.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote:
> In all seriousness, to me this is obvious. When you pass a command to the
> shell, naturally, certain details are shell-specific.
>
> -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it
> yourself. Or better yet, don't pass shell=T
Of course! And, why not escape everything else, too?
abc -> ^a^b^c
echo %PATH% -> ^e^c^h^o^ ^%^P^A^T^H^%
In all seriousness, to me this is obvious. When you pass a command to the
shell, naturally, certain details are shell-specific.
-1. Bad idea. Very bad idea. If you want the ^ to be esca
32 matches
Mail list logo
