[BusyBox] long options with no short counterpart

[Paul Fox]

 > > 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:

  enum
  {
      BLOCK_SIZE_OPTION = CHAR_MAX + 1,
      COLOR_OPTION,
      ...

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
=---------------------
 paul fox, pgf at brightstareng.com