ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
OK, thanks Colucix; I looked through the man page but the -prune option did not appear by description to function as it seems to be doing. And I agree, the functionality vs the man page looks odd. The man page claims that brackets () can be used. Maybe the OP needs to escape & quote the expression, inside the quotes defining the variable itself?
From my man page for find:
-prune True; if the file is a directory, do not descend into it. If
-depth is given, false; no effect. Because -delete implies
-depth, you cannot usefully use -prune and -delete together.
Last edited by GrapefruiTgirl; 07-28-2009 at 06:15 AM.
Well, usually the -prune action is used in conjunction with -wholename to ignore some directories from the search. An explanation of this behaviour is under the -path option (that is an old predicate for -wholename). Some time ago I wrote a post to try to explain this obscure feature of the find command.
The man page claims that brackets () can be used. Maybe the OP needs to escape & quote the expression, inside the quotes defining the variable itself?
I don't know what the exact problem is, maybe the shell is confused by so many quotes and wildcards (???) but adding eval before $FIND_COMMAND solves the issue. The problem is not in the find command itself, but in the way it is executed:
With reference to the find syntax, find takes everything on the command line as a path until the expression begins. \( is not an expression element so find is going to search both . and \(. Find continues parsing its arguments and happily munches everything as parts of expression until it gets to \) which is not an expression element. Time for an error message. What error message? Well, \) ain't an option or an expression element then it must be a path. Hence "paths must precede expression: \)"
but does it work as intended? In the same way that \ is used to prevent the shell acting on ( and ), the single quotes are used to prevent the shell doing filename expansion (more beautifully called globbing!) on the likes of *log.
That's essential on the command line, in case there are any *log files-or-directories in the current directory. But it's *log etc. you want to pass to find. I think the revised value of FIND_COMMAND above actually passes '*log' to find. "find" will dutifully look for files called '<something-or-nothing>log' with the quotes and not match the files you want it to match.
So let me just verify that I got this right: The shell consists of a reader and a runtime environment, and both makes expansions. If I pass a variable to eval, it will run through both components, but if I simply run the command within a shell script, it only goes through the latter?