[issue6208] path separator output ignores shell's path separator: / instead of \
Laurent Birtz added the comment: Thank you for the clarifications on the usage of cmd.exe and shell=True. I tend to forget that the shell support in subprocess isn't just about UNIX. The point of running msys is getting programs to work as if they were in a limited UNIX environment without the emulation layer provided by Cygwin. It's nice if programs unaware of msys work out-of-the-box, but for use cases like mine what is needed is the possibility to write a program that works correctly on msys with a minimum of fuss. Given that, conditionally setting os.dep on program entry and wrapping the calls to cmd.exe manually seems to fit the bill. I haven't tested if SCons plays nice with that change, so I may be in for a disappointment. Even if it doesn't work right, it would still be useful for me to temporarily change os.dep and join my paths correctly until I return control to SCons. On my system, print os.environ["MSYSTEM"] yields MINGW32. That's all I need for detecting msys currently. If that ever break I'll find another method. -- ___ Python tracker <http://bugs.python.org/issue6208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6208] path separator output ignores shell's path separator: / instead of \
Laurent Birtz added the comment: I agree with the "no magic bullet" point and that Microsoft is fully to blame for the situation. About the catalogue of Windows APIs that accept slashes. I've read in various places that the only problematic case is the legacy shell API. The power shell seems to accept forward slashes. http://stackoverflow.com/questions/18464038/is-it-possible-to-make-vim-use-forward-slashes-on-windows http://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash Is it reasonable to believe that most Python programs don't care about the legacy shell API? I assume that the Python library uses CreateProcess() under the hood without touching cmd.exe. Some odd Python programs may invoke cmd.exe explicitly but hopefully that is a rare case. If those assumptions hold, then changing os.sep *from the user script* would not break backward compatibility and allow Python to work as expected on MinGW. Arguably it's a simpler solution than requiring Python projects like Mercurial to tackle that issue themselves. Even if it's not the perfect solution, it's a step-up from "Non-Cygwin Python corrupts paths on MinGW and you can't make it stop". -- ___ Python tracker <http://bugs.python.org/issue6208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6208] path separator output ignores shell's path separator: / instead of \
Laurent Birtz added the comment: First, I apologize for my overly harsh tone. A dismissive comment above struck a nerve but that doesn't excuse it. @Lawrence: from my perspective it is a bug: the Python interpreter doesn't handle paths correctly on MinGW as I'd expect. As Nick said, the ideal scenario would be to come up with a solution that actually fixes the problem on MinGW. I realize that very few people use MinGW and are impacted by this, so it seems like much effort for little gain. Nevertheless, perhaps the issue could be left open until someone decides to bite the bullet and fix it properly? I'm the one complaining and it's fair that I spend the effort to fix it, but like everyone I have limited time on my hands, and I can't do this now. FWIW I see three potential solutions. I'm not involved in Python development and I don't know how applicable they are. 1) Modifying os.sep as described above. Pros: it behaves as expected from the user point-of-view. It makes sense that the separator in this variable is used internally by the module for manipulating the paths. It may be straightforward to implement by making this a property and propagating the change to the Python code and/or interpreter code whenever it is set. Cons: AFAICT there aren't obvious reasons why someone would modify os.sep currently, so it *should* be fine for backward compatibility for most users, but there is no guarantee. 2) Adding the function os.set_sep(separator). Like 1), but it's less transparent to the user, who might set os.sep naively like I did and be surprised that it doesn't work. I think that eliminates all potential backward compatibility issues though. 3) Detect MinGW. It's brittle but it makes Python behaves as expected for the user -- who might still want/depend on the current behavior however? I'm not a fan of this but it's doable. If the MinGW detection fails then the behavior falls back to the standard Windows behavior. The reverse (assuming MinGW incorrectly) is way more problematic, but I think that the odds of that happening are very low. So essentially if the detection fails then only the MinGW users are impacted. Nick, correct me if I'm wrong but the target platform for MinGW is mostly Windows itself, aside of this particular issue? The rest of the standard library seems to be working fine on MinGW as it is. Thank you. -- ___ Python tracker <http://bugs.python.org/issue6208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6208] path separator output ignores shell's path separator: / instead of \
Laurent Birtz added the comment: In my opinion, the decision to cross your arms and pretend there is no issue is unprofessional. Summary of your arguments: - It's Microsoft's fault. - Windows accepts backslashes anyway. - Shell detection is difficult. - It's a complex issue. None of this is relevant to addressing the issue ThurnerRupert was facing. He asked to be able to CONFIGURE the path seperator. This needs not involve shell detection (which is indeed brittle). This could be handled simply by the user setting 'os.sep' and having os.path.join() and friends use that. I'm using SCons on MinGW and the build is failing due to the messed-up paths. I'm less than thrilled about learning that this won't get fixed. I feel that one of the important strength of Python is that it "just works" on many platforms and this amply justifies this issue not being treated with such frivolity. -- nosy: +laurent.birtz ___ Python tracker <http://bugs.python.org/issue6208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
