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.
- Re: glibc
- From: Per Lundberg <email@example.com>