On Thu, Jun 29, 2017 at 12:37:19PM +0200, Ruediger Meier wrote:
> > than introduce another function. (It was also reason why I was not
> > sure with print_usage_help_options(), but it resolves more issues.)
>
> I can still change it to be used like MAN_TAIL, then we are consistent
> again.
>
> print_usage_help_options(16);
> vs.
> printf( USAGE_HELP_OPTIONS(16) );
Yes, I have no strong opinion about it, but somehow to have libc stuff
without any extra abstraction in the code seems always better.
> > For me it's about:
> >
> > * nice usage() output
> > * usage() function readability
> > * all without extra complexity (random contributor has to be able
> > add new option easily)
> > * translators-friendly (minimize changes, keep it open as much as
> > possible)
>
>
> I see it all like you, so let's stop code cosmetics unless we have real
> changes. I'll send a patch for boilerpalate.c only. and maybe the
> mentioned help_options macro.
I just pushed wipefs and uuidgen with puts(), it seems good. So my
suggestion
1) use libc output functions if possible
2) use puts() for new tools or after massive changes in usage()
3) don't use puts() for already translated usage()
4) use
--output <list> COLUMNS to display (see below)
...
COLUMNS:
(William, can you update your "standardize USAGE_COLUMNS" patches? Please.)
5) "perfect is the enemy of good" (your new (or first) tatto...)
6) keep our maintainer happy and send patches with new regression
tests, improve stability, implement new features, etc. :)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
