Message202822
| Author |
tim.golden |
| Recipients |
BreamoreBoy, ThurnerRupert, eric.smith, laurent.birtz, ncoghlan, r.david.murray, terry.reedy, tim.golden |
| Date |
2013年11月14日.09:27:27 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<5284977C.6020600@timgolden.me.uk> |
| In-reply-to |
<1384388469.37.0.993226465265.issue6208@psf.upfronthosting.co.za> |
| Content |
On 14/11/2013 00:21, Laurent Birtz wrote:
> Is it reasonable to believe that most Python programs don't care
> about the legacy shell API?
No more than it is to believe that most Python programs don't care about
MSys or Cygwin ;)
For information, cmd.exe will happily run, eg, "c:/windows/notepad.exe".
The problem is that command-line programs built in to cmd.exe (such as
"type" and "dir") expect the slash to prefix a command-line switch. And
they don't seem to have particularly good escape- or quote-handling.
External command-line tools, like "xcopy", will happily act on
forward-slash pathnames as long as they're double-quoted.
Now certain of the Windows shell API (and here "shell" means: the visual
elements, *not* the cmd/PS command shell) will only operate on
backslash-separated paths. For example: SHILCreateFromPath:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762210(v=vs.85).aspx
I'm not exactly how much that affects the current discussion, but my
point is that there *are* places in Windows where the backslash is the
only acceptable separator.
Changing os.sep globally is real no-no. it has the potential to break a
*lot* of code and we're in no position to assess how it's been used.
Applying a change conditionally might be acceptable, but somone would
have to work out how we knew what environment we were in.
TJG |
|