The getopt long thing breaks the tree.

[Tito]

On Wednesday 31 May 2006 16:32, Bernhard Fischer wrote:
> On Tue, May 30, 2006 at 11:06:44PM +0200, Tito wrote:
> >On Tuesday 30 May 2006 19:07, Bernhard Fischer wrote:
> >> On Tue, May 30, 2006 at 12:55:37PM -0400, Rob Landley wrote:
> >> >make allnoconfig
> >> >switch on netcat
> >> >make
> >> >
> >> >Broken build.
> >
> >Hi,
> >it seems to me that this turning off getopt_long
> >has more disvantages then advantages (only size reduction?! or are there other advantages):
> 
> <grumble>
> There are no disadvantages i can see. What are you talking about?
> </grumble>
> 
> >
> >1) there are options like --color for ls or --Istdin in hdparm (maybe others!?)
> >     that have no short option, so these options are lost.
> 
> Right.
> 
> >2) there are applets that use getopt_long themselves rather than bb_getopt_ulflags,
> >     (at the moment only hdparm) that are influenced by this config option.
> 
> hdparm and run-parts are affected, yes.
> 
> >     So you have to fix them one by one (will this increase code size at the end?)
> 
> It will most likely actually shrink these applets.

Maybe not if you try to save somehow the functionalities of the long-only options....

> >3) the options must also be removed conditionally from the usage messages (more complexity?) 
> 
> Yes, they should be conditional in the usage messages. Care to send a
> patch? :)

I'm working on it.

> >Maybe at this point it would be easier to drop long option support at all,
> >at least the design would be clearer.................
> 
> That is one possibility, yes. Go ask the maintainer ;)

8-]

> What i, personally, care about is standard compliance; There simply is no
> such thing like getopt_long nor "struct option". See
> http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html
 
Yes, I love standards..........if i set them.

> Now that i can conveniently turn that bug off by toggling
> CONFIG_GETOPT_LONG, i'm content.
> 
> dalias suggested that we implement our own minimal getopt() and
> getopt_long() replacement. I'm not too interrested in doing this myself,
> though. A SUSv3 compliant libc has to implement getopt() for us, and we
> can live without getopt_long via turning off CONFIG_GETOPT_LONG so i see
> no pressing need to get to this myself anytime soon.
> 
> >> .. Since bb_getopt_ulflags doesn't yet honor turning off the long
> >> options, yes. Fix the two occurances: bb_getopt_ulflags and
> 
> The patch to make bb_getopt_ulflags aware of CONFIG_GETOPT_LONG was
> applied a few minutes ago.
> Now that allnoconfig <turn on nc> works.

Fine. :-)

> >> run_parts_main; The latter needs to be converted to use an llist for the
> >> -a option (haven't had time to do this just yet).
> >> The former needs a (supposedly trivial) if (ENABLE_GETOPT_LONG put into
> >> the appropriate places (also haven't had time to do this yet).
> >> I converted all the rest of the applets to use the long option stuff conditionally.
> >
> >root/Desktop/busybox/miscutils/hdparm.c: In function ???hdparm_main???:
> >/root/Desktop/busybox/miscutils/hdparm.c:2137: warning: implicit declaration of function ???getopt_long???
> > 
> >Almost all, hdparm is not converted and will show unexpected behaviour 
> >with -Istdin  ;-)
> >
> >BTW.: one solution for this applet could be to drop --Istdin if nobody complains.
> >           another one could be to use '-' 
> >            hdparm -i -
> >	    or to read from stdin if after option parsing argv[optind] is NULL.
> > Hints?
> >
> >Ciao,
> >Tito
> >
> >> Please go ahead, if you find the time. 
> >> >This is in addition to the config option shouldn't say getopt, it should say 
> >> >something like "Enable --long-options".  The config entry shouldn't say the 
> >> >technical internal thing, it should say what the effect is that people 
> >> >configuring it will see.
> >> 
> >> Fair enough. I couldn't think of a better wording (i admit i just yanked and
> >> pasted the locale support block...)
>