On 06/29/2017 06:53 AM, Karel Zak wrote: > 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.) Sure, one clarification please: you want only the columns header in all caps? So: Usage: Options: Functions: Commands: COLUMNS: > > 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 > -- 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
