Fix the addgroup help output

Laszlo Papp lpapp at kde.org
Mon Aug 18 12:11:48 UTC 2014


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:

* [-fb]
* [-f] [b]
* [OPTIONS]

If that looks OK to you, then I guess you do not like unified and
simplified outputs. 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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140818/c31a238f/attachment.html>


More information about the busybox mailing list