Fix the addgroup help output

Laszlo Papp lpapp at kde.org
Mon Aug 18 12:51:00 UTC 2014


On Mon, Aug 18, 2014 at 1:42 PM, tito <farmatito at tiscali.it> wrote:

> 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?
>

It really does *not* matter what I prefer. The maintainer decides and it is
_purely_ subjective, so there is not much point in telling what I prefer.
That is the least significant point for me. Consistency is by far way above
any personal style in my book.


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

How untrue... Actually, I looked at many applet's help text. Are you
seriously claiming that you use one applet in your life? I definitely think
that is untrue. Most people use several applets along their life, looking
at several help outputs. Do you think people only work on unifying and
simplifying things for fun without any practical merit?


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

What are you talking about? You yourself claimed in the end it is
incoherent. Look at frameworks like Qt/KDE/etc who deal with applications,
and how much they unify and simplify all this. No, do not hijack please
that they are bigger than busybox; that is _not_ the point here. The point
is that they have applets/applications that they want to behave
consistently.


> > 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,
>

What-are-you-talking-about?

It is so relatively simple task that people got wrong? Are there silly
coders in busybox only? I guess not, so the process is just simply
error-prone. Not to mention, the "machinery" is called development and
improvement. Development is done for automating jobs in the world that is
repetitive, boring, utterly error-prone and Sense.Makes.All.At.No to do
again, again, and again.


> This is about fixing a simple help text, just write down how you
> want it and add it to CodingStyle.txt.
>

You completely miss the point. The whole point of the thread is not about
writing down one personal preference and done. The applets will be still
inconsistent, and the process will require manual reviews, style
investigation, and what not. Any reasonable programmer knows that this can
be automated without serious defect. Others project have done it; I am sure
busybox would be able to do it if wanted, but I realize this list has heavy
objection for almost any valid improvement which kind of makes me burning
out providing suggestions and comments, but that is not a discussion for
today...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140818/23a9635f/attachment.html>


More information about the busybox mailing list