The getopt long thing breaks the tree.

[Bernhard Fischer]

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.

>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? :)
>
>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 ;)
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

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.

>> 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...)