Would be nice if parsing and help get generated from same data structure. I think that java getopt implementation, or the one in glib (vala) does it in this way.
----- Original message ----- > 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. >
