Re: recursive grep and openoffice

[Ken Irving <fnkci@uaf.edu>]

On Wed, Mar 18, 2009 at 01:45:42PM -0500, Boyd Stephen Smith Jr. wrote:
> In <[🔎] 20090318164208.GA14318@localhost>, Ken Irving wrote:
> >On Wed, Mar 18, 2009 at 11:19:20AM -0500, Boyd Stephen Smith Jr. wrote:
> >> I think I'd rewrite it as:
> >> find . \
> >> -name '*.odt' \
> >> -exec sh -c 'unzip -c "$1" content.xml | grep -q regex' \{} \; \
> >> -print
> >>
> >> I'm not sure what the rules are for find substituting "{}" within
> >> another argument, so it seems best to write it as a separate argument. 
> >> If you have anything that matches *.odt in the current directory, the
> >> find won't work[1] unless you quote it.  You might also need to throw
> >> double-quotes around the regex, depending on its contents.
> >>
> >> [1] It may work, but it won't actually be searching for files with names
> >> matching the glob *.odt.
> >It _may_ also work if unquoted, since bash will leave the literal *
> >as is if there's no match in the current directory, and so find will
> >see it as intended.  I guess that's a good thing, but it can be
> >confusing.
> 
> I did qualify my statement with "if you have anything that matches *.odt in 
> the current directory".  Also, I think it might depend on your glob 
> expansion settings in bash.  ISTR an option to expand non-matching globs to 
> either an empty argument or no argument at all.

Understood.  My point is just that folks may have success using bare
glob patterns in some cases, but then get nailed when they end up matching
something.   My recommendation is to escape the glob metachar itself, e.g.,

    find . -name \*.odt

as I find that this sort of hints at what's going on, but YMMV.

> >Bash will also leave {} untouched since it doesn't expand to anything, so
> >I don't see any point in quoting it as shown.
> 
> Bash will, but I've heard other shells will not--something about considering 
> "{}" an empty command group.  I'm pretty sure the relevant standards require 
> {} to NOT be recognized as anything special since neither '{' or '}' is an 
> operator character, but I'd have to read them again to be sure.

Another poster mentioned enclosing the braces in quotes, "{}", to
accomodate filenames with spaces, which I've never encountered or thought
about, but then those quotes would need to be protected from the initial
shell expansion.

This all gets even more "fun" if you're doing the find on a remote system
using ssh, and the shell, ssh, the remote shell, etc., are all in there 
expanding and removing quotes and escapes.

Ken
-- 
Ken Irving