On Mon, Jan 8, 2018 at 9:26 PM, Steve Dower <steve.do...@python.org> wrote: > On 09Jan2018 0744, eryk sun wrote: >> >> It's common to discourage using `shell=True` because it's considered >> insecure. One of the reasons to use CMD in Windows is that it tries >> ShellExecuteEx if CreateProcess fails. ShellExecuteEx supports "App >> Paths" commands, file actions (open, edit, print), UAC elevation (via >> "runas" or if requested by the manifest), protocols (including >> "shell:"), and opening folders in Explorer. It isn't a scripting >> language, however, so it doesn't pose the same risk as using CMD. >> Calling ShellExecuteEx could be integrated in subprocess as a new >> Popen parameter, such as `winshell` or `shellex`. > > This can also be used directly as os.startfile, the only downside being that > you can't wait for the process to complete (but that's due to the underlying > API, which may not end up starting a process but rather sending a message to > an existing long-running one such as explorer.exe). I'd certainly recommend > it for actions like "open this file with its default editor" or "browse to > this web page with the default browser".
Yes, I forgot to mention that os.startfile can work sometimes. But often one needs to pass command-line parameters. Also, os.startfile also can't set a different working directory, nShow SW_* window state, or flags such as SEE_MASK_NO_CONSOLE (prevent allocating a new console). Rather than extend os.startfile, it seems more useful in general to wrap ShellExecuteEx in _winapi and extend subprocess. Then os.startfile can be reimplemented in terms of subprocess.Popen, like os.popen. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
