On Mon, Jan 5, 2015 at 8:02 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/04/2015 11:24 AM, random832@fastmail.us wrote:
If being cross-platform isn't easy, it won't happen. You see it now with the lack of any support for "call glob on arguments on windows and not on unix" [because the shell handles it on unix] whether directly, in argparse, or in fileinput
Could you elaborate on this point?
On Unix, a command like "python some_script.py *.txt" is parsed by the shell[1] into a bunch of extra arguments, eg "python some_script.py file_one.txt file_two.txt file_three.txt". On Windows[2], this expansion isn't done, so the script gets a literal "*.txt" as an argument. So a Unix program is usually written to accept multiple args, but a Windows program usually expects to do its own globbing. Now, what happens when you want to reference a file whose name actually includes U+002A (or \x2A, given that file names on most Linux systems consist of bytes)? On Unix, you put a backslash in front of the name, to prevent the shell from expanding it ("\*.txt"), or use some other means of calling up the program (subprocess.call(["python","some_script.py","*.txt"])). Your expectation then is that the script will NOT expand globs; but the script will see the exact same thing in sys.argv as it does on Windows, where the expectation is that it WILL expand globs (and, if I'm not mistaken, asterisks are simply disallowed in file names - though that might be a filesystem-specific rule). So somehow, your script has to know whether it's supposed to call glob or not. Or, more likely, it'll do whatever is appropriate for the platform its developer uses, and then misbehaves on the other one. ChrisA [1] Assuming you're using one of the standard shells, and assuming you haven't configured this feature away, etc, etc. Normal user expectations. [2] Again, assuming you're using the default shell; but again, normal user expectation, ergo replacement shells often replicate this.