[BusyBox] long options with no short counterpart

Paul Fox pgf at brightstareng.com
Tue Aug 2 16:25:21 UTC 2005

 > > yes, you and i talked about this before, and i remember your
 > > solution.  i consider it unacceptable to write programs which
 > > have hidden unexpected features on the command line.  if the
 > > option processing api changes, i'm happy to change the ls code to
 > > use it.
 > from fileutils-3.13:
 > static struct option const long_options[] = {
 > 	....
 > 	{"color", optional_argument, 0, 13},
 > 	{NULL, 0, NULL, 0}
 > };

i wonder why they did that?  the last element of the option
structure is an int, not a char, so there was no reason to choose
an ascii value there.  and indeed, i have a copy of fileutils-4.1
handy that reads like this:

  {"color", optional_argument, 0, COLOR_OPTION},

where COLOR_OPTION is a larger-than-char enum:


so you see that someone else feels using ascii values in that
place is a bad thing, too.

oh!  i'm an idiot.  for some reason i had it in my head that in
the interest of compactness, busybox had it's own definition of
"struct option", in which the "val" element was only a char.  i
now see that it uses the standard getopt_long and the standard
struct, and that we could do the same sort of "CHAR_MAX + 1"
trick.  as rob points out, this doesn't make i18n any easier, but
i don't see busybox tilting that windmill anytime soon.

 paul fox, pgf at brightstareng.com

More information about the busybox mailing list