find: unknown predicate `- filesdpx/2024-01-28/dtx_2024-04-10_reference.txt
 

I want to find all files in a directory called 'project' inside this directory there is a lot of different directory with the criteria */*/*20* -maxdepth 1 -type f -mmin +$((730 * 1440)) -not -path 'Archive/*' -not -path 'orphan'. After finding the files with the mentioned criteria, I want those files to be moved to the 'files.txt' file. However, while running this script: find */*/*20* -maxdepth 1 -type f -mmin +$((730 * 1440)) -not -path 'Archive/*' -not -path 'orphan/*' > files.txt
I am getting the error 'unknown predicate for find command,' which indicates that certain files have a hyphen at the beginning and a space between the hyphen and the filename. How can I fix that? I ran this line in a bash script.

I'd try running the command with quotes/double quotes around the entire path.

Is there a hyphen followed by a space in the command itself? That’s what the error you describe seems to indicate.

Use code tags to show us exactly what you ran, please. Also what, exactly, the message you got said.

you can add an echo:to see what will be really executed. And probably you can catch that invalid predicate.

hey @yancek i added the quotation but nothing changed , still have the same error .

no there is no any hyphen in the command , i was looking for files older than 180 days with the name convention 20 into specific directory , but there is an error with one directory that has a hyphen at the beginning and space in between the hyphen and the directory name , the find command is not able to go into that directory and look for files complaining about the - i am not sure how to make the find command deal with hyphen or special character to find for the files into that directory .

We need the output of above command(echo find... 2>&1 | more ) for us to reproduce the same at our environment.

Actually, there are several hyphens in the command
If any have an accidental space between the hyphen and its parameter, that would cause the error you describe, which appears to be a complaint about the construct of the command itself. As you’ve noted, the command is not working, so it can’t be complaining about the files it might have found.

So, again. Please copy/paste the command that’s erroring into code tags (see the link in my sig), and include the error you’re getting. Don’t tell us what’s happening, show us. Please.

The problem is similar to what happens with many commands when you have file or directory names that look like options. Usually, one solution is precede the name with "./" so that the string does not look like an option.

Try:

and the -path names must adapt:
Certainly -prune is more efficient:
Global option -maxdepth 1 should be valid for both -or branches.
Both -or branches have a default -print action.
An explicit -print only prints that branch:
Finally a complex variant, cannot overflow with "too many arguments":