python 2.7.12 on Linux behaving differently than on Windows
greg.ewing at canterbury.ac.nz
Tue Dec 6 02:08:32 EST 2016
> But a similar example, suppose a syntax is:
> appl *.* [options]
I would be disappointed by such a syntax. What if I want
to operate on two or more files with unrelated names? With
that syntax, I can't list them explicitly in the one command.
To make that possible, the syntax would have to be
appl filespec... [options]
i.e. allow an arbitrary number of filespecs followed by
options -- requiring the command line to be scanned looking
for options anyway.
> And if there's an error in an option, you may have to abort, which means
> throwing away that list of files which, in some cases, can run into
This "millions of files" thing seems to be an imaginary
monster you've invented to try to scare people. I claim
that, to a very good approximation, it doesn't exist.
I've never encountered a directory containing a million
files, and if such a thing existed, it would be pathological
in enough other ways to make it a really bad idea.
> But maybe people simply avoid all the situations that cause problems.
> Interfaces are specified in a certain manner, given that input can be
> any long stream of filenames and/or options with no order and no
> positional significance.
Exactly. The programs are designed with knowledge of the
way shells behave and are typically used.
> You can't do the equivalent of:
> >DIR *.b *.c
> And get a list of *.b files, with a heading and summary lines, then a
> list of *.c files with its own heading and summary.
Not with *that particular syntax*. You would need to
design the interface of a program to do that some other
> That doesn't change the fact that the Windows approach is considerably
> more flexible and allowing more possibilities.
At the expense of having shells with less powerful
facilities, and more inconsistent behaviour between
One isn't better than the other. There are tradeoffs.
More information about the Python-list