Re: fputs() vs puts()

[J William Piggott <elseifthen@gmx.com>]

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
>