It would be a nice challenge to write a really small getopt() replacement, and a program that generates usage text. Okay, how about…
usage: program -a [-b] [-c] -f file blah blah blah No grouping. Should make parsing simpler. I guess it’s still a good idea to let the user choose the order of the arguments? Can “blah blah blah” be put in between e.g. -a and -b? The usage above communicates: -a Required. Must always be set. -b Optional. -c Optional. -f file Required. file must always be a string. blah blah blah I guess it’s up to the program to decide if this is optional or required. But. If we agree that it’s okay that the usage text is unambiguous, then I can’t come up with one example of an _option_ that would ever be outputted as _required_. Compare “man fdisk” with “man dmenu”. It makes sense to separate the optional and the required options in the fdisk manual page, since they have chosen to show what combinations that work together. But if we don’t want to communicate that in the usage text, then all it does is to visually group an option with its argument. Compare these: 1. flo -c id -f from -r id -t to -w what what,from-to 2. flo [-c id] [-f from] [-r id] [-t to] [-w what] [what,from-to] Both of them say exactly the same. And these: 1. dmenu [-i] [-b] [-l <lines>] [-fn <font>] [-nb <color>] [-nf <color>] [-p <prompt>] [-sb <color>] [-sf <color>] [-v] 2. dmenu -i -b -l <lines> -fn <font> -nb <color> -nf <color> -p <prompt> -sb <color> -sf <color> -v 3. dmenu -i -b -l lines -fn font -nb color -nf color -p prompt -sb color -sf color -v The first one doesn’t contain more information than the third one.
