Re: [git pull] schedutils

[Karel Zak <kzak@redhat.com>]

On Thu, Jul 21, 2011 at 08:37:52PM +0200, Sami Kerola wrote:
> >  * I think that
> >        -c, --class NUM
> >   is better than
> >        -c, --class=NUM
> 
> With equals sign is FSFism, which seemed like good starting point...

 :-)

 The '=' is required only for optional arguments, the it's probably
 the best to use

    --foo[=NUM]

> >  I have fixed this in ionice man page, but not in usage(). It would be
> >  nice to use in all man pages and usage() functions the same syntax.
> >  Maybe we can create any template or so to have it documented.
> 
> ...but you are absolutely right again. Converting README.devel in
> small chunks to a Documentation directory might be a way to go.

 Good idea!

> Contents of the directory could have help_and_version.txt for what you
> said above, and I can recall recent minix & kernel headers
> conversation which ought also be documented.

 OK.

> BTW what would you think about having a util-linux.h with inline

 Should be enough to use c.h ?

> function to print in usage help & version option descriptions and
> proper version output function. The first would make translation teams
> happier when they do not need to write time after time the same
> translations. Second would simply unify how version is printed, and if

 Well, .po files never contains duplicate strings.

> it ever needs a modification it's easier to do.

 I agree.

> In practice the file would be similar to coreutils system.h.

 Hmm... I don't like 

  #define case_GETOPT_VERSION_CHAR(Program_name, Authors)
          case GETOPT_VERSION_CHAR:


 We don't use the same char everywhere and hide keywords (e.g. case)
 to macros is not nice too.
 
 It would be enough to use 

   case 'V':
        ul_print_version();
        break;
        
 The result should be readable C language, not any gnulib meta-language :-)

   Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com