util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ruediger Meier <sweet_f_a@gmx.de>
To: Karel Zak <kzak@redhat.com>
Cc: J William Piggott <elseifthen@gmx.com>, util-linux@vger.kernel.org
Subject: Re: fputs() vs puts() (was: [PATCH] hwclock: remove unused usage() FILE argument)
Date: Wed, 28 Jun 2017 21:29:40 +0200	[thread overview]
Message-ID: <201706282129.41161.sweet_f_a@gmx.de> (raw)
In-Reply-To: <20170620085610.5eacn7kl5agfemmk@ws.net.home>

On Tuesday 20 June 2017, Karel Zak wrote:
> On Sun, Jun 18, 2017 at 08:49:49PM -0400, J William Piggott wrote:
> >  sys-utils/hwclock.c | 74
> > ++++++++++++++++++++++++++--------------------------- 1 file
> > changed, 37 insertions(+), 37 deletions(-)
>
> It would be better to remove this patch from the pull-request; let's
> keep fputs() in the code and wait for any solution from Rudi :-)

I have now finished my cleanup regarding stdout only. To make the diffs 
small I have left a useless definition "FILE *out = stdout;" in almost 
any usage function.

We can remove this "out" variable now everwhere using a sed or awk. But 
a few questions about what would be the best end state.

1. fputs vs puts?:

   Is it a problem for translators if we remove a newline from almost
   any string? And, does puts() look more nice at all? I mean many usage
   functions have to use printf too, so does it look good if some
   strings are '\n' terminated and others not?

2. Alignment for better readabilty in the code.

   I would prefer leading spaces before the first string argument to
   match the longest possible prefix 'printf(_("'. Is that ok?:

   puts(  _(" -q             quiet mode"));
   fputs( _(" -v, --verbose  verbose mode"), stdout);
   printf(_(" -f, --rtc      use alternate to %1$s\n"), _BLA);
   printf(  "     --help     %s\n", USAGE_OPTSTR_HELP);

3. Maybe we should always decouple options and descriptions?

   Introducing a macro like:

   #define prnt_opt(opt, marg_dsc, dsc) \
       printf( "%-" #marg_dsc "s%s\n", opt, dscr)

   /* the magic margin number for the whole function */
   int m = 16;
   prnt_opt(" -q",              m, _("quiet mode");
   prnt_opt(" -v, --verbose",   m, _("verbose mode");
   prnt_opt("      --help",     m, USAGE_OPTSTR_HELP);
   /* or standard help, as exist already */
   print_usage_help_options(m);

4. About our USAGE_* macros

   We can remove the trailing newlines in all macros if puts() is
   preferred (regarding 1.). Or we can just let them print like
   print_usage_help_options().

5. We can leave everything as is and touch all these usage lines only
   if needed. For example I did it without extra noise in a861538c.
   Karel missed his chance in 4fb515f9 ;)

   Note since introducing print_usage_help_options() we *are* already
   mixing hardcoded stdout and variable out. So we can also convert
   single lines from fprintf to printf, like i did in my last pending
   hwclock patch "don't ifdef printf arguments".

cu,
Rudi

  parent reply	other threads:[~2017-06-28 19:29 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-19  0:35 [PATCH 00/12] pull request J William Piggott
2017-06-19  0:37 ` [PATCH 01/12] hwclock: remove dead code in usage() J William Piggott
2017-06-19  0:38 ` [PATCH 02/12] hwclock: update usage() to util-linux style J William Piggott
2017-06-19  0:40 ` [PATCH 03/12] hwclock: update usage() FILE name J William Piggott
2017-06-19  0:41 ` [PATCH 04/12] hwclock: add usage() functions heading J William Piggott
2017-06-20  8:36   ` Karel Zak
2017-06-21  0:59     ` J William Piggott
2017-06-21 12:21   ` Ruediger Meier
2017-06-21 15:59     ` J William Piggott
2017-06-19  0:42 ` [PATCH 05/12] include: update pathnames.h J William Piggott
2017-06-20  8:44   ` Karel Zak
2017-06-21  0:53     ` J William Piggott
2017-06-19  0:44 ` [PATCH 06/12] hwclock: use RTC in help output J William Piggott
2017-06-19  0:45 ` [PATCH 07/12] hwclock: update --help content and grammar J William Piggott
2017-06-20  8:51   ` Karel Zak
2017-06-21  0:53     ` J William Piggott
2017-06-21 13:05     ` Ruediger Meier
2017-06-21 14:55       ` Karel Zak
2017-06-21 15:30         ` J William Piggott
2017-06-22  2:04           ` Ruediger Meier
2017-06-22 18:46             ` J William Piggott
2017-06-21 15:01     ` Karel Zak
2017-06-21 17:02       ` J William Piggott
2017-06-19  0:46 ` [PATCH 08/12] hwclock: slice up the usage text J William Piggott
2017-06-19  0:47 ` [PATCH 09/12] hwclock: add --update-drift check J William Piggott
2017-06-19  0:48 ` [PATCH 10/12] Docs: update howto-usage-function.txt J William Piggott
2017-06-19  0:49 ` [PATCH 11/12] hwclock: remove unused usage() FILE argument J William Piggott
2017-06-20  8:56   ` Karel Zak
2017-06-21  0:52     ` J William Piggott
2017-06-28 19:29     ` Ruediger Meier [this message]
2017-06-29  8:51       ` fputs() vs puts() (was: [PATCH] hwclock: remove unused usage() FILE argument) Karel Zak
2017-06-29 10:37         ` Ruediger Meier
2017-06-29 10:53           ` Karel Zak
2017-06-29 14:46             ` fputs() vs puts() J William Piggott
2017-06-29 20:12               ` Karel Zak
2017-06-30 18:29                 ` J William Piggott
2017-07-03  8:30                   ` Ruediger Meier
2017-07-03 12:07                     ` Karel Zak
2017-07-03 12:38                       ` Ruediger Meier
2017-07-03 14:25                         ` Karel Zak
2017-07-03 15:09                           ` Bernhard Voelker
2017-07-03 15:15                             ` Bernhard Voelker
2017-06-29 10:37         ` fputs() vs puts() (was: [PATCH] hwclock: remove unused usage() FILE argument) Karel Zak
2017-06-21  9:26   ` [PATCH 11/12] hwclock: remove unused usage() FILE argument Karel Zak
2017-06-21 15:48     ` J William Piggott
2017-06-25 21:39       ` J William Piggott
2017-06-19  0:51 ` [PATCH 12/12] hwclock: remove unused stdarg.h J William Piggott
2017-06-21  9:27 ` [PATCH 00/12] pull request Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201706282129.41161.sweet_f_a@gmx.de \
    --to=sweet_f_a@gmx.de \
    --cc=elseifthen@gmx.com \
    --cc=kzak@redhat.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).