| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Certain options are available in all of these programs (in fact, every GNU program should accept them). Rather than writing identical descriptions for each of the programs, they are described here.
2.1 Backup options -b -S -V, in some programs. 2.2 Block size BLOCK_SIZE and --block-size, in some programs. 2.3 Target directory --target-directory, in some programs. 2.4 Trailing slashes --strip-trailing-slashes, in some programs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GNU programs (at least cp, install, ln, and
mv) optionally make backups of files before writing new versions.
These options control the details of these backups. The options are also
briefly mentioned in the descriptions of the particular programs.
VERSION_CONTROL
environment variable is used. And if VERSION_CONTROL is not set,
the default backup type is `existing'.
Note that the short form of this option, `-b' does not accept any argument. Using `-b' is equivalent to using `--backup=existing'.
This option corresponds to the Emacs variable `version-control'; the values for method are the same as those used in Emacs. This option also accepts more descriptive names. The valid methods are (unique abbreviations are accepted):
SIMPLE_BACKUP_SUFFIX
environment variable is used. And if SIMPLE_BACKUP_SUFFIX is not
set, the default is `~', just as in Emacs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GNU programs (at least df, du, and ls) display
file sizes in "blocks". You can adjust the block size to make file
sizes easier to read. The block size used for display is independent of
any filesystem block size.
Normally, disk usage sizes are rounded up, disk free space sizes are rounded down, and other sizes are rounded to the nearest value with ties rounding to an even value.
The default block size is chosen by examining the following environment variables in turn; the first one that is set determines the block size.
DF_BLOCK_SIZE
df command.
Similarly, DU_BLOCK_SIZE specifies the default for du and
LS_BLOCK_SIZE for ls.
BLOCK_SIZE
POSIXLY_CORRECT
command_BLOCK_SIZE nor the BLOCK_SIZE
variables are set, but this variable is set, the block size defaults to 512.
If none of the above environment variables are set, the block size currently defaults to 1024 bytes, but this number may change in the future.
A block size specification can be a positive integer specifying the number
of bytes per block, or it can be human-readable or si to
select a human-readable format.
With human-readable formats, output sizes are followed by a size letter
such as `M' for megabytes. BLOCK_SIZE=human-readable uses
powers of 1024; `M' stands for 1,048,576 bytes.
BLOCK_SIZE=si is similar, but uses powers of 1000; `M' stands
for 1,000,000 bytes. (SI, the International System of Units, defines
these power-of-1000 prefixes.)
An integer block size can be followed by a size letter to specify a
multiple of that size. When this notation is used, the size letters
normally stand for powers of 1024, and can be followed by an optional
`B' for "byte"; but if followed by `D' (for "decimal
byte"), they stand for powers of 1000. For example,
BLOCK_SIZE=4MB is equivalent to BLOCK_SIZE=4194304, and
BLOCK_SIZE=4MD is equivalent to BLOCK_SIZE=4000000.
The following size letters are defined. Large sizes like 1Y
may be rejected by your computer due to limitations of its arithmetic.
human-readable,
or 10^3 = 1000 for si.
Block size defaults can be overridden by an explicit
`--block-size=size' option. The `-k' or
`--kilobytes' option is equivalent to `--block-size=1k', which
is the default unless the POSIXLY_CORRECT environment variable is
set. The `-h' or `--human-readable' option is equivalent to
`--block-size=human-readable'. The `--si' option
is equivalent to `--block-size=si'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GNU programs (at least cp, install, ln, and
mv) allow you to specify the target directory via this option:
The interface for most programs is that after processing options and a
finite (possibly zero) number of fixed-position arguments, the remaining
argument list is either expected to be empty, or is a list of items
(usually files) that will all be handled identically. The xargs
program is designed to work well with this convention.
The commands in the mv-family are unusual in that they take
a variable number of arguments with a special case at the end
(namely, the target directory). This makes it nontrivial to perform some
operations, e.g., "move all files from here to ../d/", because
mv * ../d/ might exhaust the argument space, and ls | xargs ...
doesn't have a clean way to specify an extra final argument for each
invocation of the subject command. (It can be done by going through a
shell command, but that requires more human labor and brain power than
it should.)
The --target-directory option allows the cp,
install, ln, and mv programs to be used conveniently
with xargs. For example, you can move the files from the
current directory to a sibling directory, d like this:
(However, this doesn't move files whose names begin with `.'.)
ls |xargs mv --target-directory=../d |
If you use the GNU find program, you can move all
files with this command:
find . -mindepth 1 -maxdepth 1 \ | xargs mv --target-directory=../d |
But that will fail if there are no files in the current directory
or if any file has a name containing a newline character.
The following example removes those limitations and requires both
GNU find and GNU xargs:
find . -mindepth 1 -maxdepth 1 -print0 \
| xargs --null --no-run-if-empty \
mv --target-directory=../d
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GNU programs (at least cp and mv)
allow you to remove any trailing slashes from each source
argument before operating on it. The --strip-trailing-slashes
option enables this behavior.
This is useful when a source argument may have a trailing slash and
specify a symbolic link to a directory. This scenario is in fact rather
common because some shells can automatically append a trailing slash when
performing file name completion on such symbolic links. Without this
option, mv, for example, (via the system's rename function) must
interpret a trailing slash as a request to dereference the symbolic link
and so must rename the indirectly referenced directory and not
the symbolic link. Although it may seem surprising that such behavior
be the default, it is required by POSIX.2 and is consistent with
other parts of that standard.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |