util-linux/Documentation/howto-usage-function.txt

158 lines
5.5 KiB
Plaintext
Raw Normal View History

Well-known options
------------------
Following options are well-known, and they should not be used for any
other purpose.
-h, --help display usage and exit
-V, --version display version and exit
Rule of thumb with other options is that once they exist you may not
change how they work, or remove them.
Notice that `-?' is not expected to be synonym of --help, but an unknown
options resulting to a usage print out due getopt failure.
How usage is supposed to look
-----------------------------
The usage output begins with empty line followed by `Usage:' and synopsis
beginning on the next line. Synopsis and all other lines which vary are
indented by one space (0x40).
The synopsis line describes how to execute the command. Sometimes you may
need multiple synopsis lines, this is documented separately under Synopsis
title.
Notations; Diamond brackets markup an argument. Anything optional is
marked with square brackets, such as optional command arguments, or
optional option arguments. In the later case `=' character in front of
the option argument, because one has to use it. Square brackets with
three dots inside mean unlimited repetition of previous.
Short option are always written first followed by long option. Options are
separated with comma and one space. Lonely short or long option do not
affect where writing of the option begins.
Below, in between snips, is an example of how the usage output should
look like.
-- snip
Usage:
program [options] <file> [...]
Options:
-n, --no-argument option does not use argument
-o, --optional[=<arg>] option argument is optional
-r, --required <arg> option requires an argument
-z no long option
--xyzzy a long option only
-e, --extremely-long-long-option
use next line for description when needed
-l, --long-explanation an example of very verbose, and chatty option
description on two, or multiple lines, where the
consecutive lines are intended by two spaces
-f, --foobar next option description resets indent
-h, --help display this help and exit
-V, --version output version information and exit
For more details see program(1).
-- snip
Notice that there are usage function definitions in c.h include file
which you must use. Location of example is mentioned at the end of this
file.
Option description
------------------
Option description should not exceed width of 80 characters. If you need
longer description use multiple lines and indentation.
The description begins from the point of longest option plus two spaces.
In case adding a new option would cause a description re-indentation
need it either has to be done, or the new option should begin description
from next line. Usually the later is better. The --help and --version
will not follow this rule, since they are defined as constants to ease
translation work.
The argument, e.g. `arg', can be better. For example if an option is
expecting number as argument a `num' is suitable argument description.
Order of the options has no special meaning, with a exception of --help and
--version which are expected to be last ones of the list.
Last line of the usage print out is either empty, or a message informing
about manual page. For example: `For more details see example(1).' In
between man page message and options there is empty line.
Usage function
--------------
Standard usage function takes either stderr or stdout as an argument. The
argument will determine whether the program will exit with error or
success. Usage function will never return.
In the code all strings with options have to start at the same position. See
bellow what that means.
fprintf(out, _(" -x[=<foo>] default foo is %s"), x);
fputs( _(" -y some text"), out);
docs: usage function and gettext I made following survey which was sent to all email addresses in po/ directory that had the on-going millenium as time when translator had been active. There are two quite common styles to write a command usage print out, which one you prefer? 1. Each option as separated translatable string. 18 votes 2. Or the whole thing as one big output. 1 vote 3. No preference. 1 vote The questionaire had also free text field asking 'Why do you prefer that?', and here are the answers. [Separately] It is easier to follow changes with the translations. If you change only one line or two, the big string would change to fuzzy and I have to check the whole thing to see what was changed in the original. If the changed line is a single string, the string to check is a lot shorter. [No preference] Usually, if there is no reason to separate strings, better keep them together so that the context is obvious. In the case at hand, it might help if in some language e.g. one translated line is too wide for the screen. This is unlikely, but... OTOH, with this solution, if you change one string the whole translation will be discarded until a translator comes and updates it... [Separately] It may be a bit harder to get the formatting right, but it is much easier in maintenance. With one option changing, the translator immediately sees the spot. And even with a lazy translator, program author will have all the options translated that have not changed at all. [Separately] First one would be more in elegant I believe [Separately] I prefer to have them separately because they don't form a single text paragraph. In other words, they can be translated separately because they are complete and separate "sentences". Of course consistency of format and word choices need to be taken care of, but the fact that the messages appear next to each other in the PO file should be enough. Also if the options are not translated separately, adding or editing one option causes the translation of all options to become fuzzy and if for some reason it isn't checked before next release (happens sometimes), all of them will show untranslated to the user. [Separately] Translations are a lot easier to update that way. If an option is added, removed or changed, only a small amount of text becomes fuzzy. If everything is in one big output, a lot of text becomes fuzzy, and you have to read a lot more text to discover what exactly changed. [Separately] When updating a fuzzy translation, with one big output it's very tedious and error-prone to find out the reason for fuzziness, i.e. what actually has changed in the msgid. [Separately] Way easier to translate, and especially to spot translation updates when one string gets removed, added or modified. [Separately] Makes translation memory more efficient. Some hard terms in the list don't prevent translation of the whole block. Actually the beginning of the strings don't need any translation ta all before [] part. Information about the context can be provided in comments or the context parameter. [Separately] Please consider the case when a part of string, (= msgid) is changed. It is marked as fuzzy in the .po files, we translators have to check whole sentences for the difference between it and previous version. [Separately] Every sentence must be a separate translation unit. [One big output] for performance to ouput strings [Separately] In the second case, if only one option changes (or a new one is added), the translator will see as if all of the options changed, having to find out which one of them is really new or has actually changed. Also, if the translator has had no time to update the string, only one of the options will be shown in the original language (which is arguably ugly, but better than nothing for many users). [Separately] It's easier to translate the options separately using translation memory. [Separately] Easier to separate and see changes [Separately] more translator friendly [Separately] From the user POV I found the separeted version more interesting because if a maintainer can't update the translation fast enough between releases the user will still get the current translated string with the new ones untraslated. From the translator POV the big output will give more context information as one can see the whole command options. With a new string added while the rest is translated having some context can be more difficult. [Separately] Additions to the list or changes to one options means you don't have to check all lines each time. So unless you have very, _very_ good reason you should not output all usage as one big table. This implies also that when large usage output is changed it should be split to small hunks. That may be a bit more work once, but the next change will pay the extrawork off so never hesitate when splitting. Reference: http://www.surveymonkey.com/s/QKZ75HK Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2013-01-22 17:27:00 -06:00
Be nice to translators. One gettext entry should be one option, no more,
no less. For example:
fputs(_(" --you-there be nice\n"), out);
fputs(_(" -2 <whom> translators\n"), out);
fputs(_(" -t, --hey are doing job that we probably cannot,"
" or how is your klingon?\n"), out);
When existing usage output is changed, and it happens to be one big
output, split it to chunks size of an option. The extra work for
translators will pay off at the time of the next change when they do not
need to search from fuzzy markup what has changed, where, how, and was it
the only change.
Synopsis
--------
You may need to use multiple synopsis lines to tell that a command does
fundamentally different things depending on options and/or arguments. For
example ionice either changes priority of a running command, or executes
a program with a defined priority. Therefore it is reasonable to have two
synopsis lines.
ionice [options] -p <pid> [...]
ionice [options] <command> [<args>] [...]
Notice that the synopsis is not meant to be repetition of options segment.
The fundamental difference in execution is a bit difficult to define
other than usually command author, package maintainer or patch submitter
will know when it should be done that way.
Legacy options
--------------
Some commands use peculiar options and arguments. These are supported,
but such will not be accepted in future. See list bellow for a hint what
are meant this.
- Other than `-' used to define an option. See `+' for `more'
commands.
- Option string used as an option argument. See `more' command and `-num'.
- Short long option. See `setterm'.
Example
-------
Command disk-utils/delpart.c is a minimal example how to do write usage
function, setup option parsing, version printing and so on.