[BusyBox] long options with no short counterpart
Vladimir N. Oleynik
dzo at simtreas.ru
Wed Aug 3 12:28:10 UTC 2005
Paul,
> > > 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.
ftp://ftp.simtreas.ru/pub/my/bb/new
have also:
- new getopt_ulflags()
The last argument from struct getopt_long (val)
can undefined from applet_opts (short form).
If you use this, then:
- return bit have next position after short options
- if has_arg is not "no_argument", use ptr for arg also
- bb_opt_complementaly have effects for this too
- corrected "ls" applet for example
Tested.
--w
vodz
More information about the busybox
mailing list