найти файлы (find files)
Обоснование (Rationale)
The -a operator was retained as an optional operator for
compatibility with historical shell scripts, even though it is
redundant with expression concatenation.
The descriptions of the '-' modifier on the mode and onum
arguments to the -perm primary agree with historical practice on
BSD and System V implementations. System V and BSD documentation
both describe it in terms of checking additional bits; in fact,
it uses the same bits, but checks for having at least all of the
matching bits set instead of having exactly the matching bits
set.
The exact format of the interactive prompts is unspecified. Only
the general nature of the contents of prompts are specified
because:
* Implementations may desire more descriptive prompts than
those used on historical implementations.
* Since the historical prompt strings do not terminate with
<newline> characters, there is no portable way for another
program to interact with the prompts of this utility via
pipes.
Therefore, an application using this prompting option relies on
the system to provide the most suitable dialog directly with the
user, based on the general guidelines specified.
The -name file operand was changed to use the shell pattern
matching notation so that find is consistent with other utilities
using pattern matching.
The -size operand refers to the size of a file, rather than the
number of blocks it may occupy in the file system. The intent is
that the st_size field defined in the System Interfaces volume of
POSIX.1‐2017 should be used, not the st_blocks found in
historical implementations. There are at least two reasons for
this:
1. In both System V and BSD, find only uses st_size in size
calculations for the operands specified by this volume of
POSIX.1‐2017. (BSD uses st_blocks only when processing the
-ls primary.)
2. Users usually think of file size in terms of bytes, which is
also the unit used by the ls utility for the output from the
-l option. (In both System V and BSD, ls uses st_size for the
-l option size field and uses st_blocks for the ls -s
calculations. This volume of POSIX.1‐2017 does not specify ls
-s.)
The descriptions of -atime, -ctime, and -mtime were changed from
the SVID description of n ``days'' to n being the result of the
integer division of the time difference in seconds by 86400. The
description is also different in terms of the exact timeframe for
the n case (versus the +n or -n), but it matches all known
historical implementations. It refers to one 86400 second period
in the past, not any time from the beginning of that period to
the current time. For example, -atime 2 is true if the file was
accessed any time in the period from 72 hours to 48 hours ago.
Historical implementations do not modify "{}" when it appears as
a substring of an -exec or -ok utility_name or argument string.
There have been numerous user requests for this extension, so
this volume of POSIX.1‐2017 allows the desired behavior. At least
one recent implementation does support this feature, but
encountered several problems in managing memory allocation and
dealing with multiple occurrences of "{}" in a string while it
was being developed, so it is not yet required behavior.
Assuming the presence of -print was added to correct a historical
pitfall that plagues novice users, it is entirely upwards-
compatible from the historical System V find utility. In its
simplest form (find directory), it could be confused with the
historical BSD fast find. The BSD developers agreed that adding
-print as a default expression was the correct decision and have
added the fast find functionality within a new utility called
locate.
Historically, the -L option was implemented using the primary
-follow. The -H and -L options were added for two reasons.
First, they offer a finer granularity of control and consistency
with other programs that walk file hierarchies. Second, the
-follow primary always evaluated to true. As they were
historically really global variables that took effect before the
traversal began, some valid expressions had unexpected results.
An example is the expression -print -o -follow. Because -print
always evaluates to true, the standard order of evaluation
implies that -follow would never be evaluated. This was never the
case. Historical practice for the -follow primary, however, is
not consistent. Some implementations always follow symbolic links
on the command line whether -follow is specified or not. Others
follow symbolic links on the command line only if -follow is
specified. Both behaviors are provided by the -H and -L options,
but scripts using the current -follow primary would be broken if
the -follow option is specified to work either way.
Since the -L option resolves all symbolic links and the -type l
primary is true for symbolic links that still exist after
symbolic links have been resolved, the command:
find -L . -type l
prints a list of symbolic links reachable from the current
directory that do not resolve to accessible files.
A feature of SVR4's find utility was the -exec primary's +
terminator. This allowed filenames containing special characters
(especially <newline> characters) to be grouped together without
the problems that occur if such filenames are piped to xargs.
Other implementations have added other ways to get around this
problem, notably a -print0 primary that wrote filenames with a
null byte terminator. This was considered here, but not adopted.
Using a null terminator meant that any utility that was going to
process find's -print0 output had to add a new option to parse
the null terminators it would now be reading.
The "-exec...{}+" syntax adopted was a result of IEEE PASC
Interpretation 1003.2 #210. It should be noted that this is an
incompatible change to IEEE Std 1003.2‐1992. For example, the
following command printed all files with a '-' after their name
if they are regular files, and a '+' otherwise:
find / -type f -exec echo {} - ';' -o -exec echo {} + ';'
The change invalidates usage like this. Even though the previous
standard stated that this usage would work, in practice many did
not support it and the standard developers felt it better to now
state that this was not allowable.
