[issue39692] Subprocess using list vs string
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 but with a recent bash from homebrew): $ bash -c 'exit 1' # like subprocess string case $ echo $? 1 $ bash -c exit 1 # like subprocess list case (note args are separated) $ echo $? 0 -- nosy: +jweese ___ Python tracker <https://bugs.python.org/issue39692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39692] Subprocess using list vs string
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 happens that bash code that
consists of a single executable calls it -- useful behavior in a shell.)
Consider:
$ bash -c 'f() { printf "%s\n" "$@"; }; f "$@"' - foo bar baz
foo
bar
baz
> 1) If there exist use cases for setting `shell=True` and doing "bash -c
> my_executable arg2 arg3", then the documentation should say something like
> the following:
> """
> Using `shell=True` invokes the sequence of args via `bash -c`. In this case,
> the first argument MUST be an executable, and the subsequent arguments will
> be stored as bash parameters for that executable (`$0`, `$1`, etc).
> """
I'd be okay with clearer docs, but the given language is not quite right. For
example, the actual shell call is /bin/sh (and depends on the platform). And,
as described above, I think it would be too restrictive to say the first
argument must be a single executable.
On the other hand, I disagree with option 2. I think raising an error would be
very restrictive, and secretly quoting the argument could be surprising for
(the few) people who understand the underlying shell mechanism.
--
___
Python tracker
<https://bugs.python.org/issue39692>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39692] Subprocess using list vs string
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 produces a subtle
> difference: the arg in the position of `$0` is used as an actual positional
> parameter in one case, and as the shell name in the other case
It is not quite just a shifting of the positional args.
$ bash -c 'f() { printf "%s\n"; }; f "$@"' - foo bar baz
=> "From a string, read this bash script, which defines a function f and then
invokes f on all of its arguments. Now invoke that script with an executable
name of "-" and the arguments "foo" "bar" and "baz".
$ bash -c 'f() { printf "%s\n"; }; f "$@" - foo bar baz'
=> "From a string, read this bash script, which defines f and then invokes f on
all the script arguments as well as "-" "foo" "bar" and "baz". Then invoke that
script with no other arguments."
--
___
Python tracker
<https://bugs.python.org/issue39692>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
