Fix the addgroup help output

[tito]

On Monday 18 August 2014 14:11:48 you wrote:
> On Mon, Aug 18, 2014 at 1:07 PM, tito <farmatito at tiscali.it> wrote:
> 
> > On Monday 18 August 2014 10:50:18 Laszlo Papp wrote:
> > > On Mon, Aug 18, 2014 at 9:45 AM, walter harms <wharms at bfs.de> wrote:
> > >
> > > >
> > > >
> > > > Am 17.08.2014 11:22, schrieb Denys Vlasenko:
> > > > > On Fri, Aug 15, 2014 at 3:11 PM, <lpapp at archlinux.us> wrote:
> > > > >
> > > > >>  Applets are defining the help display text on their own, and it is
> > > > >> different for different applets.
> > > > >>
> > > > >
> > > > > I don't see any obvious way to make it easier without significant
> > bloat.
> > > > >
> > > > > Pass a list of options, parameters and their explanations to a
> > function
> > > > > which builds help text? This will likely be bigger than the help text
> > > > > (many pointers to small strings results in pointers taking
> > > > > almost the same amount of space than strings!)
> > > > >
> > > > > Even if you manage to avoid _that_ bloat somehow,
> > > > > you can't bzip2-compress tiny bits of text.
> > > > > We currently bzip2-compress our help text as one big blob,
> > > > > with BIG savings in size - more than 50%
> > > > >
> > > > > And then you discover that some applets really want a bit
> > > > > of customization to the way how options are explained.
> > > > >
> > > > >
> > > >
> > > > Would that something for busybox.net/TODO section ?
> > > > "Verify that help text and option are in sync"
> > > >
> > >
> > > Would what for TODO? It should not never really be validated by a human
> > in
> > > the first place. An applet author should just fill in the metadata. All
> > the
> > > rest should be automatically handled IMHO. Otherwise, it is error-prone,
> > > will likely only cause the chaos that the applets have now with regards
> > to
> > > this.
> > >
> >
> > HI,
> > if you would like to take a look at busybox/docs/BusyBox.html
> > there are displayed all help texts, most of them look ok to me,
> > a few could need some fixes, so lets list them. It would be
> > also useful to write down exactly to what standards we want
> > to enforce. KISS.
> >
> 
> I am not sure what you are looking at. They are  completely inconsistent.
> They use at least three different schema for just the options, let alone
> others:

Which one do you prefer?

This could be ok for indipendent options.
> * [-fb]
This could be ok for options that depend on each other 
or eventually [-f[b]]
> * [-f] [b]
THis could be ok for the short usage form  FEATURE_VERBOSE_USAGE [=n]
as there are applets that have 20 or more options and
[qwertyuiopasdfghjklzxcvbnm] is not better than simple [options].
> * [OPTIONS]


> If that looks OK to you, then I guess you do not like unified and
> simplified outputs.

I just would like to point out that you rarely look at more than 
a help text at a time and this is maybe the because nobody
complained so far.

> That is definitely not any KISS you are referring to. I
> would advise you to have a closer look than what you have apparently done.
> 
> But let us imagine that for a second that what you are saying is true: it
> is still extremely cumbersome, error-prone, and nonsensical IMHO to write
> the help output yourself, either a rewrite for an existing or creating it
> for a new one. 

Most of the help texts out there are written exactly that way
(by hand) and surprisingly the people out are able to get this
job done in a coherent way..

> The applet author ought to be responsible only for the
> metadata, and no any more boilerplate.
> 
> I think you just simply do not see the forest from the trees here, or the
> communication has just severely failed to bring the attention to the actual
> issue.
> 

I feel you would like to add even more trees by adding a machinery for
a relatively simple task that has to deal with a lot of exceptions
and later on needs to be maintained by somebody,
This is about fixing a simple help text, just write down how you
want it and add it to CodingStyle.txt.

Ciao,
Tito