python 2.7.12 on Linux behaving differently than on Windows

BartC bc at
Wed Dec 7 07:23:00 EST 2016

On 07/12/2016 05:15, Steven D'Aprano wrote:
> On Wednesday 07 December 2016 12:55, BartC wrote:
>> But even Linux's 128KB will fill if someone wanted a command line that
>> listed 20,000 files individually. But it would be spectacularly bad use
>> of a command line interface which was designed for humans.
> That's EXACTLY the point of having the shell do globbing.

Sorry, it's got NOTHING to do with it!

Here's a command that works on all one million files in the current path:

  program *.*

11 characters, so Linux still has 131061 left (assuming 'program ' is 
part of it).

But Windows will also have 8181 characters left (or 8180, whatever). And 
the shell hasn't needed to do any 'globbing'.

Now we come to the next bit, where the program in question has an entry 
point that looks like 'main(argc, argv)', where some function splits up 
the command line.

In Windows, argc is 2 (name of program, and the "*.*" parameter). If the 
program wants to process all one million files, it will have to scan 
them one at a time, but it does not need to build a list first.

In Linx, argc will be 1000001, and the program will still need scan them 
one at a time (although it won't need to call an OS function to do the 

In neither case was the command line limit an issue.

But I can see where you're coming from: if someone was silly enough to 
want to specify all one million filenames on the command line, then they 
will eventually come up to the limit. On both systems.

That is not going to happen however. And is nothing to do with how or 
where *.* expansion is done.

>     command fooba?.jpg {here,there}/*.jpg  another/place/*.{png,jpg} [a-z]/IMG*

   list fooba?.jpg {here,there}/*.jpg  another/place/*.{png,jpg} \
     [a-z]/IMG* > files

   command @files

Only 'list' needs to understand all this crap (and more besides). 
Applications only need to understand '@'. Or maybe @files /can/ be 
expanded by the shell, more acceptable here because it's explicit.


More information about the Python-list mailing list