There is no substitute for reading source code. grep -A20 -ri "usage:" src-directory should get you started. But if you rely on looking only at usage(), you'

There is no substitute for reading source code. grep -A20 -ri "usage:" src-directory should get you started. But if you rely on looking only at usage(), you'll miss "undocumented" features. Try reading the OpenSSH source for example. There is at least one undocumented option. If the source code is so voluminous and the organization of the project so convoluted that it is prohibitive to scanning through the source to figure out what the program does, then that in itself tells you something. The smaller the program (and its source code), the easier it is to master it, in my humblest opinion. Generally, the larger the program, the higher the probability of bugs and vulnerabilities. This, you might say, is the cost of adding "features". I prefer small programs where I can read the source code quickly and easily. They need not have many features. The less output the better. As long as they do one thing well enough, and reliably. Not to mention what it does to ease of use every time you add more "features" to a program. Look at the OpenSSL binary. It is like they are going for the World Record on the number of options you can cram into a single command line program. Insane.