It'll get better through rewrites, new tools, different infrastructures etc long before it gets better through iteration on the same tools. That's OK though :)
2) Now paralell is better
3) Never. You should be able to check the man pages even if you can't access the binaries.
2. GNU Parallel is actually my choice for this, because xargs has a few known issues. Parallel gets the most right, and I used it a lot in my research to run scripts on lots of data.
3. Hell no. Distributions do this job perfectly fine, and you should be able to read the man pages without having read permissions for the binary (since in UNIX you can have 111 as permissions on a binary).
No, it actually won't. There are so many tricks and caveats with shell expansions, wildcard handling etc, that regularly old unix hats I know get it wrong (and I've started on Sun OS, probably before half of HN was born).
This is like saying "pointers are nothing, you can learn them in a day" ignoring the obvious fact that the interplay with pointers in a large app is something entirely different than merely understanding indirection, and than even the best kernel/driver/crypto/etc programmers still get pointer related bugs after decades of writing C.
>3. Hell no. Distributions do this job perfectly fine, and you should be able to read the man pages without having read permissions for the binary (since in UNIX you can have 111 as permissions on a binary).
Actually, no, they don't do it at all. One can have 3-4 different versions of a userland program, and never know (unless they explicitly check versions) for which the man page is.
On the contrary; there have been many valid reasons to evolve them, but backward compatibility was deemed more important.
Example #1: it is possible to write a sh/csh/bash/?sh script that handles file names with spaces, slashes, quotes, question marks, etc, but one would hope that would be made a bit easier, almost half a century later.
Example #2: the hack that is xargs for handling large numbers of arguments. To write a truly robust script that handles directories with an arbitrary number of files, one should run a pipeline using find and xargs, instructing xargs to do the actual work (and you cannot even use find and xargs with their default settings; you need -print0 and -0 flags to handle file names with spaces, etc)
If programs received arguments unexpanded, and the system had a library for expanding arguments, many use cases would become a lot simpler, and scripts could become more robust.
And yes, that could have been evolved. Headers of executables could easily contain a bit indicating "I'll handle wild-card expansion myself".
Example #3: man pages, IMO, should be stored in a special section inside binaries. That ensures that the man page you read is the man page for the executable you have.
Example #4: http://unix.stackexchange.com/questions/24182/how-to-get-the... shows that things _have_ evolved. Reading and parsing /etc/mtab isn't a reliable way to find all mount points, just as reading /etc/passwd file isn't the way to find password hashes anymore, ar has long been upgraded to support file names longer than 14 characters, and zip knows more file attributes than it used to.