Why are POSIX Find Parameters Different from Other Program styles?

Question

Why is a parameter in the POSIX find command added with a single hyphen for multi-character parameter names, while most other programs use single hyphen to indicate multiple single-character flags, and double-hyphens to indicate single parameter names with multiple characters?

This seems inconsistent, and I'm curious as to

A. why it's really not inconsistent, or
B. the history of that decision.

Answer 1

Note that POSIX find does support options like other commands, and -- to mark the end of them like other commands. Those are -H and -L.

The -print, -type... are not options, they're sometimes called predicates. They are arguments whose order matters that appear after the file paths which themselves appear after the options. You've also got ( and !. Together, they build an expression that is used to determine what files to find.

find is not the only one. [ (aka test) and expr are other commands whose arguments are used to build an expression.

Like find, [ has operators that start with - and are more than one-letter (-gt, -eq...).

Like find, test has issues where those operators may be confused with operands.

find -- "$file1" "$file2" -type f
[ -f "$file1" -a -f "$file2" ]

If $file2 is !, it's a problem with find. If it's =, it's a problem with (some) [.

For all of find, test and expr, using options to build the expression would not really have worked. Another option could have been to have one string evaluated as the expression like awk or sed. like for

find f1 f2 \( -type f -mtime -1 -o ! -type f -newer x \) -exec ls -ld {} +

Do:

find 'found = 0
      if (typeof($f) == "f") {
        if (age($f) > 1) found=1
      } else if (age($f) < age("x")) found = 1
      if ($found) exec_multi("ls -ld {}")' f1 f2

But that means implementing a grammar parser in find. That also means potential quoting nightmare for the "x" and command line above.

Actually AT&T Research did come up with such a command: tw (tree walker), but even though it's now open source, I'm not aware that it is really used out of AT&T.

Answer 2

find is older than the GNU convention of using -- for multi-letter options. GNU introduced this convention to break the existing inconsistency between programs with single-letter options, to which -bar meant the three options -b -a -r, and programs with multiple-letter options, to which -bar meant a single option by that name. By the time GNU came by, it could influence future programs, but not change existing programs such as find or others such as X11 utilities.

find used - as a prefix to predicates and actions because they are somewhat like options: they are keywords, part of a finite set that is meaningful for a particular command. Although they are not parsed like options, they are lexicographically like options.

Answer 3

I think there was no conscious decision to make find different. I have no references apart from this email exchange, but from what I recall (having used find since the mid eightees):

What you have to realise is that there was no standard to begin with for specifying options and arguments (as command line arguments to programs). Different programs implemented different ways of doing things. At some point the single dash for options and non-dash for arguments became reused/copied from often used commands, and version of getopt became available, both for shells as well as for versions in C. ( I remember having had to compile my own version because the *nix I worked on did not have it in a library).

Of course the single dash, single character options fitted the tty restrictions (the same that leads to shortened commands (cp vs. copy), but where not self explanatory. The developers of find probably chose to lengthen the option single character for more clarity as well as more than the 26 lower-case character options. They did so before the double dash -- for long options became popular (mid ninetees IIRC).

The original man page had the following at the bottom:

BUGS
     The syntax is painful.