> For example, the naive way to run foo on all your .c files in one go is: find . -type f -name "*.c" -exec foo {} \+ That would break on Windows much earli

> For example, the naive way to run foo on all your .c files in one go is: find . -type f -name "*.c" -exec foo {} \+ That would break on Windows much earlier, the limit there is 32k as the article mentions. This example has nothing to do with globbing, you're recursively enumerating all .c files in the find process and building the command's arguments. On Windows, likewise, find would build a huge command line that exceeds 32k chars and fail. For this example to make sense, you'd need a recursive glob (which can be enabled in bash) but on Windows yet again the actual tool you're invoking would need to implement that. I wouldn't bet too many do that. > It all works, but isn’t ideal, and I think using a library to do argument parsing would help here (variable expansion may be a problem I mean, we basically have that on Windows since NT, but as the article shows, people/compilers do whatever. It wouldn't be any better on Linux I can tell you. :) Also, variable Expansion would be impossible in a library that's used by the invoked tool, as they never leave the shell for security reasons if you don't make them part of the environment. EDIT: copied the wrong find example earlier