This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients bhou, larry, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
Date 2015-09-07.04:16:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1441599378.56.0.174124355402.issue25005@psf.upfronthosting.co.za>
In-reply-to
Content
subprocess with shell=True turns it into a "cmd.exe /C "start chrome.exe ..."" type command, which means the arguments will use shell parsing (e.g. > for redirection, & for multiple commands, etc.)

"start" in cmd.exe behaves the same as os.startfile, but can also accept arguments. Patch 1 lets startfile accept arguments, so we don't have to go via cmd.exe to launch the browser (we're still resolving it via the shell, so the behaviour is the same, but the arguments are never interpreted using shell rules). All the functionality of #8232 is still there and still works.

Patch 2 is a rollback of #8232, so we ship the same functionality as in Python 3.4. Because this only supports the default browser and does not support selecting between new tab/window, it can go back to using os.startfile without arguments.

A third option would be to find some other way to discover the full path to each browser and launch it without using start/os.startfile. (This is what I was thinking originally when I said it would be too big a change.)
History
Date User Action Args
2015-09-07 04:16:18steve.dowersetrecipients: + steve.dower, paul.moore, larry, tim.golden, r.david.murray, zach.ware, bhou
2015-09-07 04:16:18steve.dowersetmessageid: <1441599378.56.0.174124355402.issue25005@psf.upfronthosting.co.za>
2015-09-07 04:16:18steve.dowerlinkissue25005 messages
2015-09-07 04:16:17steve.dowercreate