[asdfgadsfgasfdg]

How does

      s(command_from_potentially_unsafe_source).run()

compare with

      os.system(command_from_potentially_unsafe_source)

or

      subprocess.call(command_from_potentially_unsafe_source, shell=True)

securitywise? I'm assuming all three are equally bad?

[AkshatM]

I looked at the source code. Under the hood, it's just a thin wrapper around `subprocess`.

[asdfgadsfgasfdg]

Cool subprocess is a little verbose. But did you happen to notice if it executes with shell=True or shell=False?

[mintplant]

Do you include Python 3.5's subprocess.run in that assessment? I find it much cleaner for the common cases than the rest of the API:

https://docs.python.org/3/library/subprocess.html#using-the-...

[asdfgadsfgasfdg]

I hadn't actually noticed that! It looks like .run() allows input and output to be piped and the return code captured. That is a serious improvement over subprocess.call().

[icebraining]

Doesn't seem that different from call()

[asdfgadsfgasfdg]

It looks like it allows stdin, stdout, stderr and return code to be handled properly which call() doesn't. It's still syntactic sugar over Popen() and communicate() but will cut down boilerplate for calling external processes.