Brandon S. Allbery KF8NH wrote:
On 2008 Jun 29, at 19:40, Isaac Dupree wrote:
maybe these can be resolved somehow without keeping really verbose documentation: what do other people think? Are these cases obscure but nevertheless standard cases of getopt since Unix/GNU history? (e.g. it seems that compilers behave differently from "normal programs", behave differently from everyone else's slightly different implementations of arguments)
On of the points of getopt is that -fFLAGS and -f FLAGS both work without any extra code. Standard getopt doesn't do optional arguments at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random options -v, -x, the former taking an optional argument; the latter two cases are recognized as argument omitted).
ah-ha, so it is an unpleasant behaviour of ambiguity resolution. Oh, well, I don't know what I want. But then saying "-v[n]" to me seems a little more misleading to say than "-v [n]" although they really mean the same thing (what if "-v[n]" makes me think "-v foobar.txt" would pass foobar.txt as a positional argument rather than a verbosity level?). Proposal #3 is to just say "-v". It took me a while to figure out how passing arguments to short and long options worked at all (one requires the presence of "=", the other requires its absence... again, except for exceptions such as ghc), so I might err on the side of being more verbose, less obscure. -Isaac