Jonny Weese added the comment:
> So the command_string provided (the first word or the first quoted
> expression) is interpreted as a shell program, and this program is invoked
> with the remaining words as its arguments.
Correct.
> As you say, simply slapping quotes around all the args pro
Niklas Smedemark-Margulies added the comment:
Good point - the phrasing I suggested there is not accurate, and there is more
complicated behavior available than simply specifying a single executable.
Here's the bash manual's info about "-c" flag:
"""
If the -c option is present, then command
Jonny Weese added the comment:
> it seems strange/wrong to invoke an executable via "bash -c executable arg1
> arg2", rather than just "executable arg1 arg2"!
I agree it's strange to invoke a single executable that way, but remember that
-c allows a string of arbitrary bash code. (It just ha
Niklas Smedemark-Margulies added the comment:
Thanks very much for getting back to me so quickly, and for identifying the
reason for the difference in behavior.
Sorry to harp on a relatively small behavior, but it cost me a few hours and it
might cause confusion for others as well.
It still
Jonny Weese added the comment:
I believe this behavior is expected (at least in posix-land).
Lib/subprocess.py L1702 shows that whenever shell=True, the args that are
constructed are [unix_shell, "-c"] + args.
And so we can reproduce your behavior just using a regular shell. (This is
Darwin
New submission from Niklas Smedemark-Margulies :
Most (all?) of the functions in subprocess (run, Popen, etc) are supposed to
accept either list or string, but the behavior when passing a list differs (and
appears to be wrong).
For example, see below - invoking the command "exit 1" should giv
