[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Handling of output errors from -fprintf and similar predicates
From: |
James Youngman |
Subject: |
Handling of output errors from -fprintf and similar predicates |
Date: |
Sat, 5 May 2007 14:38:45 +0100 |
POSIX defines the -print predicate always to return true. Findutils
honours this requirement.
At the moment the -fprintf predicate has an indeterminate return value
and does not reliably detect output errors. Failing to detect output
errors is not acceptable. I propose to modify the bahaviour of
-print, -fprint, -printf and -fprintf so that in case of output error,
all of them will ensure that find exists with a nonzero status. An
error message will be issued where appropriate.
The -print predicate must always return 0. POSIX does not specify the
other options.
Should -fprintf and friends also return false when an output error
occurs? Imagine this example:-
find . -type f -fprint /foo/vanilla-files.txt -o -fprint /bar/other-files.txt
The intent of the user is plainly to list ordinary files in
/foo/vanilla-files.txt and list everything else (directories, for
example) in /bar/other-files.txt. If an output error causes -fprint
to fail and /foo is nearly full, then vanilla files will be listed in
/foo/vanilla-files.txt until /foo is full. After that point, vanilla
files will be listed in /bar/other-files.txt until foo becomes
not-full again. That seems to me to be
1. contrary to the user's obvious intent
2. surprising to the user
3. difficult to recover useful data from (unless we can repeat the
file command completely)
The consideration gives me to believe that it is the right thing for
-fprint and friends always to succeed. But can anybody think of
use-cases or other reasons which would cause us to lean the other way?
james.
- Handling of output errors from -fprintf and similar predicates,
James Youngman <=