Possible alternative, safer run() interpolation about invoke HOT 7 OPEN

When I learned about invoke and run, my first though was, "Can I pass command args as a list of strings as I can with subprocess.run?" The documentation at https://docs.pyinvoke.org/en/stable/api/runners.html#invoke.runners.Runner.run didn't answer that for me, because it wasn't clear if the option of passing a list of args was possible but not mentioned, or not possible. I agree with #2 (comment) that

… it would be nice to update run’s documentation to reflect that escaping isn’t provided and mention the risks so users can make an educated decision.…

This could just be a single sentence in http://docs.pyinvoke.org/en/stable/api/runners.html#invoke.runners.Runner.run, or mentioning the lack of escaping of the command parameter. Perhaps with a link back to this issue for further info.

If there was a way to vote for making the command parameter into *command, I'd be voting for it. I dislike invoking shells unless I really want to use the shell. And I like being protected from getting the shell's syntax or escaping wrong.

from invoke.

I'd absolutely love to use plumbum inside invoke. It's become my de-facto scripting "language" since I knew it.

Anyways, I think that being able to pass an argv list instead of a string is really needed, no matter the implementation.

from invoke.

Another angle on this is the use of tools like sh.py or plumbum, which attempt to bridge arbitrary shell string execution with Python-level function invocations. The latter can easily protect against injection style attacks because all the parameters/flags/values/etc are being handled independently and can be filtered/transformed before/while constructing the final string (or list/vector).

I'm not at all sure I want to pull in one of those or use it as the primary invocation style, but it should definitely be considered as an option.

And re: the SQL-style parameter substitution in this ticket's description, I'm on the fence as to whether that should be default or not. Being secure by default is a great idea, but it's unclear whether untrusted input is a big concern here - most users of eg Fabric and Makefiles are running their own commands or commands from an implicitly-trusted shared codebase.

from invoke.

Suggest making the issue title clearer. Something like,

Allow argc list for command in run(), like subprocess.run()

The existing title "Possible alternative, safer run() interpolation" doesn't mention "argc" or "list" or "command", which are the keywords that are most prominent in my mind. And "subprocess.run()" is now an obvious model for invoke to resemble. It wasn't there when this issue was opened, was it?

from invoke.

@pfmoore notes that this style of invocation (list-based instead of string-based) is also beneficial on some Windows platforms, see link to #312 above.

from invoke.

Seems there's a(n old) PR for this, #341 - linking for possible use when I get to this.

from invoke.

I see there are two PRs open to address this, #341 and the more recent #698. I’m not able to judge whether they are in any position to be approved and merged – in the meantime I think it would be nice to update run’s documentation to reflect that escaping isn’t provided and mention the risks so users can make an educated decision.

This could just be a single sentence in http://docs.pyinvoke.org/en/stable/api/runners.html#invoke.runners.Runner.run, or mentioning the lack of escaping of the command parameter. Perhaps with a link back to this issue for further info.

I’d be very happy to make that documentation PR, or do what I can to help get #341 / #698 merged, if someone more experienced with the project can provide guidance.

from invoke.