Hi Bruno,
Bruno Haible wrote:
I think that it would be better to fix the problem for good by deprecating
getopt_long and recommending instead something that defines the options in
one place, as Arg_parser does. Even if this implies some minor changes in
the programs to adapt to the new (simpler)
nd
> > less to keep consistent for developers.
>
> I like this idea, and was thinking in the same direction, because
> the missing consistency check between long and short options is only
> one of the nine (!) shortcomings of the getopt_long() API.
>
> What do you think about
Hi Antonio,
> I think that it would be better to fix the problem for good by deprecating
> getopt_long and recommending instead something that defines the options in
> one place, as Arg_parser does. Even if this implies some minor changes in
> the programs to adapt to the new (simpler) interfac
ing in the same direction, because
the missing consistency check between long and short options is only
one of the nine (!) shortcomings of the getopt_long() API.
What do you think about the attached proposed API? Feedback welcome.
Bruno
options.tar.gz
Description: application/compressed-tar
Ben Pfaff writes:
>> I propose to add to getopt_long() — in Gnulib — code that verifies
>> the consistency between the two places, when a certain environment
>> variable (say, GETOPT_DEBUG) is set. And produces output on stderr
>> such as:
>> getopt_long: warning: option '--context' requires an
On Tue, Jun 24, 2025 at 6:16 PM Bruno Haible via Gnulib discussion
list wrote:
>
> I propose to add to getopt_long() — in Gnulib — code that verifies
> the consistency between the two places, when a certain environment
> variable (say, GETOPT_DEBUG) is set. And produces output on stderr
> such as:
Hi Bruno,
Bruno Haible wrote:
The problem is that the properties of an option have to be specified
in *two* places: in the long_options array *and* in the 3rd argument
to getopt_long().
I propose to add to getopt_long() - in Gnulib - code that verifies
the consistency between the two places, wh
Hello!
Le mercredi 25 juin 2025 à 10:06 -0700, Paul Eggert a écrit :
> It would be nice to do the getopt check statically, if we're going to
> do
> it at all.
>
> While we're on the getopt topic, glibc might add translation of
> getopt
> argument strings:
>
> https://sourceware.org/pipermail/l
On 2025-06-25 08:09, Antonio Diaz Diaz wrote:
I think that it would be better to fix the problem for good by
deprecating getopt_long and recommending instead something that defines
the options in one place
It's a question of reinventing the wheel yet again, vs patching the
wheel we have.
I
Hi Bruno,
Bruno Haible via Gnulib discussion list writes:
> The problem is that the properties of an option have to be specified
> in *two* places: in the long_options array *and* in the 3rd argument
> to getopt_long().
>
> I propose to add to getopt_long() — in Gnulib — code that verifies
> the
Collin Funk wrote:
> > The problem is that the properties of an option have to be specified
> > in *two* places: in the long_options array *and* in the 3rd argument
> > to getopt_long().
> ...
> I wonder that the historical rational was for having the third
> parameter, the short options, in 'getop
The 'getopt-gnu' module is one of the most heavily used modules
of Gnulib (more than 50 packages use it) and it, together with
'xalloc' and 'regex', one of the first three modules a package
typically uses.
So, I thought, I can use it in my packages, without expecting problems.
Today, I wrote this
12 matches
Mail list logo
