Solved find -f undocumented?

The find(1) page shows:

find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression]

What does -f mean?

I would have thought it's trivial. Just give the path for the start of the search. It doesn't seem to work that way.

$ find -f /tmp -newer /boot/kernel/kernel

I get an error "find: illegal option -- n", presumably from the -newer expression.

Historically, I would use:

$ find /tmp -newer /boot/kernel/kernel

FWIW, I firmly believe that if a person fully understands find, they have achieved guru status. In other news, I recently learned why its dangerous to use find with -exec rm {}. I'm surprised I dodged that bullet for the last 25 years. People talk about rm -rf being dangerous. Pikers!
 
Last edited:
-f DIR solves a problem that isn't really a problem in my opinion: find -f -xdev '(' -not -type d ')' is inferior to find ./-xdev '(' -not -type d ')' when you're passing the resulting paths to a utility like rm(1):
Code:
$ find -f -xdev '(' -not -type d ')' -exec rm -i '{}' ';'
rm: illegal option -- e
usage: rm [-f | -i] [-dIPRrvWx] file ...
       unlink [--] file
In case you're still lost, this is the command being executed: rm -i -xdev/FILE. Even if the rm utility had a '-e' option, it would need to accept an argument ('v/foo' in this case); otherwise, the command would still be invalid because the '-v' option does not accept an argument ('/foo' in this case).

You could continue using -f DIR and simply follow a rule that you specify any options you need explicitly and follow the option list with -- to denote the end of the options, except some utilities like echo(1) and cc(1) don't understand -- in quite the same way as other utilities, if they understand it at all:
Code:
$ find -f -xdev '(' -not -type d ')' -exec echo -- '{}' ';'
-- -xdev/foo
$ find -f -xdev '(' -not -type d ')' -exec cc -c -- '{}' ';'
cc: warning: -xdev/foo: 'linker' input unused [-Wunused-command-line-argument]
$ find -f -xdev '(' -not -type d ')' -exec cc -c -x c -- '{}' ';'
error: invalid value 'dev/foo' in '-x dev/foo'

It's easier and less error-prone to forget about -f DIR entirely and rely on ./DIR in such rare cases. NetBSD and OpenBSD both continue to document the option at the time of this post, but it was intentionally removed from FreeBSD in r237035, a few months before 9.1-RELEASE. You can find the documentation in the 9.0-RELEASE man page. Unfortunately, I wasn't able to find the reason for its removal; it has been over 8½ years after all.
 
I read BUGS but I didn't get how it applied. memreflect's examples helped.

Now I have a second question. I don't think I've ever had to bother helping a program distinguish between its options and its arguments. Did I simply slide right be this peculiarity? Perhaps find(1) is unique in this regard?

A trivial example would be 'grep -options pattern filename'. I've never puzzled about how it parses everything after 'grep'.
 
I don't think I've ever had to bother helping a program distinguish between its options and its arguments.
Try creating or deleting a file that starts with a dash. Odd way to create files, sure. But you can easily create them by mistyping or some weird application settings.

Code:
dice@williscorto:/tmp/test % touch -- -test
dice@williscorto:/tmp/test % ll
total 1
-rw-r--r--  1 dice  wheel  0 Feb 21 21:49 -test
dice@williscorto:/tmp/test % ls -la
total 10
-rw-r--r--   1 dice  wheel    0 Feb 21 21:49 -test
drwxr-xr-x   2 dice  wheel    3 Feb 21 21:49 .
drwxrwxrwt  79 root  wheel  104 Feb 21 21:49 ..
dice@williscorto:/tmp/test % touch -test
touch: out of range or illegal time specification: [[CC]YY]MMDDhhmm[.SS]
dice@williscorto:/tmp/test % rm -test
rm: illegal option -- t
usage: rm [-f | -i] [-dIPRrvWx] file ...
       unlink [--] file
dice@williscorto:/tmp/test % rm -- -test
dice@williscorto:/tmp/test %
 
Well now. That is useful. How did I never ever have to learn that, even when I was a "professional" geek? Thanks guys.
 
Back
Top