When are grouped parentheses for multiple options necessary?

Question

I am using the find and grep commands.

Getting quite confused about when multiple options are joined by "or" with the -o flag and the use of grouped parentheses, and when grouped parentheses are not used.

When using find, grouped parentheses seem necessary

find $fdir ( -name *.texi -o -name *.org )

When using grep, grouped parentheses not used

grep --include "*.texi" --exclude "*.org"

Answer 1

Most programs, including grep don't treat parenthesis as arguments specially. If you did this:

grep "(" --include "*.texi" --exclude "*.org" ")"

grep would treat the first ( as the pattern to search for, and the last ) as a filename.^(*) Same as if they were foo and bar instead. So, you can't group options to grep.

---

But here's the thing: -name, -type, -o, and ( etc. aren't options to find. It does take some options, namely -P/-H/-L, which affect symlink processing, but these aren't options. Instead, they're part of the search expression, which is a thing specific to find. ^(**)

Emphasis on expression there. When you give find the expression ( -name *.texi -o -name *.org ) it's more like the C-like expression

( patternmatch(filename, "*.texi") || patternmatch(filename, "*.texi") )

than anything else. And find evaluates that expression for each file it sees. If you had e.g. this instead:

( -name *.texi -o -name *.org ) -printf something

You'd need the parens, because without them:

-name *.texi -o -name *.org -printf something

would be the same as

-name *.texi -o -name *.org -a -printf something

because there's an implied and between atoms unless -o is given, and then the expression would be

patternmatch(...) || patternmatch(...) && printf(...)

and the and operation binds tighter than the or operation, exactly in the same way it does in pretty much all programming languages, and in the same way multiplication binds tighter than addition. And find can't know what you wanted, because it supports arbitrary expressions.^(***) So, in this case, it wouldn't work like you want without the parens.

---

As others noted, the command you have doesn't need parens, since if there are no "actions" (-print, -exec etc.) in the find expression, it defaults to printing matching filenames, and also implicitly puts parenthesis around the expression.

So,

find "$fdir" -name "*.texi" -o -name "*.org"

acts like

find "$fdir" \( -name "*.texi" -o -name "*.org" \) -print

but if you explicitly put the -print there, you also need to explicitly put the parenthesis to get the processing order right. See: `find` with multiple `-name` and `-exec` executes only the last matches of `-name`

---

Going back to grep: grep doesn't take parens, and doesn't need them, since it doesn't process expressions. It has no concept of nesting or operators like and and or in general. Instead, it has hard-coded behaviours. With --include and --exclude, I think it tries to fulfil both the include and exclude rules at the same time. (Or, at least one of the individual --include rules and none of the individual --exclude rules.) But with multiple search patterns, it's enough to match one, or another. Both of these are static rules: you can't give it a more complicated expression of which patterns should match.

---

_{(* GNU grep would take the middle ones as options, other implementations might take them as filenames too, as the non-option argument earlier stopped option processing. Also, you need to quote or escape the parens to prevent their special meaning to the shell; that's unrelated to what grep does with them.)}

_{(** In the same way that it's specific to grep that the first non-option argument is a pattern, and only the rest are filenames, or that the last argument to mv is a destination while the others are files to move, and it's specific to git what it does with whatever arguments it takes. The tools do different things, so they have to use the command line arguments in different ways.)}

_{(*** Someone once said that evaluating expressions is the main thing find does. That is to say, it doesn't find filenames to print them, it goes through a tree of files to evaluate an expression on them. Printing and running external commands is just a side-effect.)}

Answer 2

There’s no general rule: what a given command recognises as arguments depends on the command. grep doesn’t use parentheses for grouping arguments.

For find, parentheses are only needed when the precedence of and versus or needs to be overridden; this is similar to the use of parentheses in mathematics. In your example, they are not needed, because the default precedence gives the expression the same overall meaning:

find "$fdir" -name '*.texi' -o -name '*.org'

Answer 3

The reason for the confusion is that there is no standard on how command-line parameters are interpreted by programs. In general, interpretation of parameters is left to the programmer, though the GNU coding standard recommends that programs use the getopt() and getopt_long() functions (from the GNU C library) for that purpose.

That means that the interpretation of the parentheses to define operator precedence is a function of find, and not of the shell used to invoke find. The programmers of grep "simply" didn't implement their options-parsing algorithm that way, so grep wouldn't understand this notation in the first place.

Note, however that parentheses have a special meaning in the shell: They denote that the enclosed content is a command to be run in a sub-shell. So, the command as you posted it should actually not work; as mentioned by @terdon, you have to escape the parentheses (like \( ... \)) in order to have the shell pass them to find in the first place.

Answer 4

I think the manual has some insights on how find uses the parenthesis that can help you:

2.12 Combining Primaries With Operators

Operators build a complex expression from tests and actions. The operators are, in order of decreasing precedence:

( expr )

Force precedence. True if expr is true.

! expr
-not expr

True if expr is false. In some shells, it is necessary to protect the ‘!’ from shell interpretation by quoting it.

expr1 expr2 expr1 -a
expr2 expr1 -and expr2

And; expr2 is not evaluated if expr1 is false.

expr1 -o expr2 expr1 -or expr2

Or; expr2 is not evaluated if expr1 is true.

expr1 , expr2

List; both expr1 and expr2 are always evaluated. True if expr2 is true. The value of expr1 is discarded. This operator lets you do multiple independent operations on one traversal, without depending on whether other operations succeeded. The two operations expr1 and expr2 are not always fully independent, since expr1 might have side effects like touching or deleting files, or it might use -prune’ which would also affect expr2`.

find searches the directory tree rooted at each file name by evaluating the expression from left to right, according to the rules of precedence, until the outcome is known (the left hand side is false for -and, true for -or), at which point find moves on to the next file name.