docs: trivial documentation fixes and improvements
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
This commit is contained in:
parent
96cf9d07af
commit
89c6bb4dad
|
@ -1,7 +1,7 @@
|
|||
What is here
|
||||
------------
|
||||
|
||||
The util-linux contains suplementary textual material, such as
|
||||
The util-linux contains supplementary textual material, such as
|
||||
readme files, release notes, licenses and so on. Common to these
|
||||
files is that they contain information for contributors but
|
||||
should not end up to end user installation.
|
||||
|
|
|
@ -26,7 +26,7 @@ Why: useless for kernel >= 2.6.9
|
|||
What: arch(1) command
|
||||
Why: deprecated in favor of uname(1) or arch(1) from coreutils
|
||||
|
||||
The arch(1) has been added (during 2.13 development cycle) to coreutuls
|
||||
The arch(1) has been added (during 2.13 development cycle) to coreutils
|
||||
where it will be maintained as an alias for uname(1) command.
|
||||
|
||||
----------------------------
|
||||
|
|
|
@ -24,7 +24,7 @@ called "platters", which rotate about a central axis. Devices called
|
|||
"heads" move to specified places on the disk surface to read or write
|
||||
information. There is usually one head on each side of every platter,
|
||||
and all these heads are attached to a comb-like controller arm which
|
||||
moves all of them at the same time, either closer to the centre of the
|
||||
moves all of them at the same time, either closer to the center of the
|
||||
disk, or closer to the outer edge.
|
||||
|
||||
Suppose the arm is in one position, putting an area of the disk
|
||||
|
@ -117,7 +117,7 @@ on your disk. If you set aside a partition for some purpose, it is not
|
|||
easy to change its size: you must backup all the data from the partition,
|
||||
whether to floppies, to another partition, to another hard disk, or
|
||||
somewhere else; then you must edit the table which describes this
|
||||
partition, so changing its size; then you must reboot and initialise
|
||||
partition, so changing its size; then you must reboot and initialize
|
||||
the new partition, formatting it, for example, under DOS, or running
|
||||
`mkfs' under Linux; finally you can copy all the data back. It is
|
||||
possible, if you have several partitions, to copy data back and forth
|
||||
|
@ -388,7 +388,7 @@ specify the size of a partition in megabytes, kilobytes, or in the
|
|||
current units (cylinders or sectors). A plus sign `+' indicates that
|
||||
your answer is a size rather than a boundary, and the suffix `m' or `k'
|
||||
(upper or lower case) indicates that the size is not given in units of
|
||||
sectors or cyliners, but in megabytes or kilobytes respectively. Thus
|
||||
sectors or cylinders, but in megabytes or kilobytes respectively. Thus
|
||||
possible answers to the last cylinder request above are
|
||||
|
||||
700
|
||||
|
|
|
@ -23,9 +23,9 @@ It is fully compatible with other getopt(1) implementations.
|
|||
|
||||
COPYING
|
||||
|
||||
This program comes under the GNU general public licence version 2. See the
|
||||
This program comes under the GNU general public license version 2. See the
|
||||
file COPYING included in this package. Note that though you may freely
|
||||
copy it, it is copyright (c) 1997-2005 by Frodo Looijaard
|
||||
copy it, it is copyright (c) 1997-2005 by Frodo Looijaard
|
||||
<frodo@frodo.looijaard.name>.
|
||||
Files in the gnu directory are from glibc-2.0.4: copyright (C) 1987, 88,
|
||||
Files in the gnu directory are from glibc-2.0.4: copyright (C) 1987, 88,
|
||||
89, 90, 91, 92, 93, 94, 95, 96, 97 Free Software Foundation, Inc.
|
||||
|
|
|
@ -3,7 +3,7 @@ util-linux build system
|
|||
|
||||
- all util-linux specific autoconf macros use UL_ prefix
|
||||
|
||||
- utils in Makedile.am files are enabled/disabled according to BUILD_<NAME>
|
||||
- utils in Makefile.am files are enabled/disabled according to BUILD_<NAME>
|
||||
conditions (AM_CONDITIONAL), for example:
|
||||
|
||||
if BUILD_HWCLOCK
|
||||
|
|
|
@ -42,19 +42,19 @@ The libmount & libblkid
|
|||
-----------------------
|
||||
|
||||
Both of the libraries can be debugged by setting an environment variable
|
||||
consistig a number. The number will be used as a bit mask, so the more 1 the
|
||||
greater the debugging level. Seach for `DEBUG' from files
|
||||
consisting of a number. The number will be used as a bit mask, so the more 1 the
|
||||
higher the debugging level. Search for `DEBUG' from files
|
||||
|
||||
libblkid/src/blkidP.h
|
||||
libmount/src/mountP.h
|
||||
|
||||
to see what the different bit mean. At the time of writing this the following
|
||||
to see what the different bits mean. At the time of writing this the following
|
||||
enabled full debug.
|
||||
|
||||
export LIBBLKID_DEBUG=0xffff
|
||||
export LIBMOUNT_DEBUG=0xffff
|
||||
|
||||
The libblkid reads by default /etc/blkid.conf which can be overriden by the
|
||||
The libblkid reads by default /etc/blkid.conf which can be overridden by the
|
||||
environment variable BLKID_CONF. See manual libblkid/libblkid.3 for details
|
||||
about the configuration file.
|
||||
|
||||
|
@ -62,9 +62,9 @@ Block device information is normally kept in a cache file (see blkid man page
|
|||
for more information about the cache file location) that can be overridden by
|
||||
the environment variable BLKID_FILE.
|
||||
|
||||
To libmount uses three paths, which can be override by using environment
|
||||
To libmount uses three paths, which can be overridden by using environment
|
||||
variables. Notice that these environment variables are ignored for non-root
|
||||
users
|
||||
users.
|
||||
|
||||
env variable if not set defaults to
|
||||
LIBMOUNT_FSTAB /etc/fstab
|
||||
|
|
|
@ -37,7 +37,7 @@ Tell in description an
|
|||
.I argument
|
||||
is optional, and what happens when is or is not given. Notice that
|
||||
.I argument
|
||||
is not abreviated, like in usage function. Assuming usage function would
|
||||
is not abbreviated, like in usage function. Assuming usage function would
|
||||
define argument to be
|
||||
.IR num ,
|
||||
the manual page should say
|
||||
|
@ -83,12 +83,12 @@ When in the source a new sentence begins somewhere midline, it should use a
|
|||
double space before its initial letter. This is done because groff uses double
|
||||
spaces last sentence ends to end of line, and next begins from new line.
|
||||
Unless double spaces are used in middle of of line the spacing style is
|
||||
inconsistant.
|
||||
inconsistent.
|
||||
.SH ENVIRONMENT
|
||||
Tell which environment variables affect, and how, to execution of the command.
|
||||
.TP
|
||||
.B EXAMPLE_PATH
|
||||
Configuratio file path. Notice that a well-known environment variables such as
|
||||
Configuration file path. Notice that a well-known environment variables such as
|
||||
.B HOME
|
||||
does not need explanation.
|
||||
.SH FILES
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Well-known options
|
||||
------------------
|
||||
|
||||
Following options are well-known, and they should not be used to any
|
||||
Following options are well-known, and they should not be used for any
|
||||
other purpose.
|
||||
|
||||
-h, --help display usage and exit
|
||||
|
@ -17,12 +17,12 @@ options resulting to a usage print out due getopt failure.
|
|||
How usage is supposed to look
|
||||
-----------------------------
|
||||
|
||||
The usage output begins with empty followed by `Usage:', and on next line
|
||||
there synopsis begins. Synopsis, and all other lines which vary, are
|
||||
intended by one space (0x40).
|
||||
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 tells how to execute the command. Some times you may
|
||||
need multiple synopsis lines, this documented separately under Synopsis
|
||||
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
|
||||
|
@ -31,11 +31,11 @@ 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 is always wrote first followed by long option. Options are
|
||||
separated with comma and one space. Lonely short or long option does not
|
||||
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.
|
||||
|
||||
Bellow, in between snips, is an example of how the usage output should
|
||||
Below, in between snips, is an example of how the usage output should
|
||||
look like.
|
||||
|
||||
-- snip
|
||||
|
@ -75,7 +75,7 @@ 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 will would cause a description re-indentation
|
||||
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
|
||||
|
@ -121,7 +121,7 @@ synopsis lines.
|
|||
ionice [options] -p <pid> [...]
|
||||
ionice [options] <command> [<args>] [...]
|
||||
|
||||
Notice that the synopsis not meant to be repetition of options segment.
|
||||
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.
|
||||
|
|
|
@ -4,7 +4,7 @@ Release schedule
|
|||
The util-linux uses <major>.<minor>.<maint> version numbering.
|
||||
Since the major version is pretty much fixed the release means an
|
||||
upgrade of minor number. Minor version is update roughly twice
|
||||
per year. Easiet way to estimate when next version will occur is
|
||||
per year. Easiest way to estimate when next version will occur is
|
||||
to see time stamp of previous release.
|
||||
|
||||
Before a release there are few release candidates, which will be
|
||||
|
@ -16,8 +16,8 @@ restricted. Usually there are two release candidates.
|
|||
rc1 1-2 weeks bug fixes only
|
||||
rc2 1-2 weeks translations, fatal/trivial bug fixes
|
||||
|
||||
The lengty time, usually about five months, after the release can
|
||||
be considered as merge window.
|
||||
The period between a release and next release candidate can be considered as
|
||||
merge window.
|
||||
|
||||
Release criteria
|
||||
----------------
|
||||
|
|
Loading…
Reference in New Issue