On Mon, 19 Jul 1999, Per Lundberg wrote: #> BTW, I've stayed away from the fine-grain, hair-splitting #> and spitball-throwing arguments, so what *is* so "wrong" #> with GNU getopt()? .... # # From a BSD point of view? It's LGPL:ed. Besides, some people seem to # dislike the long arguments (which I can't understand, since there's always # short alternatives too). You'd better ask those people; I really like the # GNU getopt myself.
As do I. And being a part of the BSD community myself I believe what "we" don't like is it being a part of libc. It has nothing to do with being GPL'd to many of us. The only things that belong in libc are prescribed by POSIX and the getopt that is, is already in BSD's libc. Add-ons belong in a library of their own because then it is very easy to test for their existence. It all boils down to POLA. If you find a getopt.h and a libgnu.a/libgnugetopt.a on my box then use it, otherwise assume my libc contains what is standard and not what's nice to have in some instances. If someone writes a getopt_long (and Brian Feldman doesn't beat you to it with a BSD version), LGPL's it, makes it a part of a library separate from libc, and makes it a standard knob on a prominent Linux distribution (Debian would be cool :), then it would be accepted without much fuss at all. Don't believe me, subscribe to the hackers list (or catch it in the archives in a couple of days) and tune into the conversation that is heading exactly in this direction right now. -steve
