This primary causes find to stop traversing the filesystem and
exit immediately if a previous condition was met. If no value is
specified, the exit value will be 0, else n. Note that other
primaries will be evaluated and acted upon before exiting.
Ok matt@, garbled@.
-false This primary always evaluates to false. This can be used follow-
ing a primary that caused the expression to be true to make the
expression to be false. This can be useful after using a -fprint
primary so it can continue to the next expression (using an -or
operator, for example).
This was brought up on the tech-userlevel list in October.
Using -fprint on findutils or new NetBSD find(1) does not do what
I wanted. For example, if saving results of all files that start
with a vowel or saving results of all files owned by group operator,
then the list of files owned by group operator would not include
the files starting with a vowel.
findutils's find has a workaround for this with -false and also a
"," comma opeator. (I made add this comma operator later; you can use
the comma to perform multiple independent tests.)
code) comes from findutils; it behaves the same.
From my manpage addition:
-fprint filename
This primary always evaluates to true. This creates filename or
overwrites the file if it already exists. The file is created at
startup. It writes the pathname of the current file to this
file, followed by a newline character. The file will be empty if
no files are matched.
Here is an example usage:
find /etc \( -name "*pass*" -fprint file1 \) -o \( -group operator -fprint file2 \) -o -name "w*"
Note that this example will NOT include entry in file2 if it is
matched in first expression. (This also is same behaviour as
findutils, and I have implemented a -false primary to handle that.
I will commit it later.)
This creates the file as command line argument parsing time.
If there is an error somewhere on that line, such as missing values
or mismatched parenthesis, then a file may still be created.
(Even if a later -fprint filename is unwritable.) This is similar
behaviour to findutils. (It has been suggested that this find could
be code to create the files in an extra stage after the command-line
argument parsing and before the actual function processing.)
I will add -fprintx and -fprint0 soon.
This was discussed on tech-userlevel.
making it clear that at least one file/directory argument is required
in both the manual and usage. "find" with no args currently barfs but
these documents implied it would do something useful.
lukem