On 3/6/23 12:08, Carlos E. R. wrote:
Maybe:
cer@Telcontar:~> find . -type d -not -readable -prune -path ./.dosemu _________________________________________________^^^^^^^^ you forgot a -o after the -prune
-prune -path ./.cache -prune -o -name "*.png" -newermt 2023-01-01 __^^^^^^^^ likewise.
No:
./.cache/thumbnails/normal/91f916ae750a5dca8f2020fb68648166.png ./.cache/thumbnails/normal/028af4e97867a90eb4551b5be73a1e30.png ./.cache/thumbnails/normal/bd6057d9fa3d308ad94a610aa1f185c3.png ^C
One needs a training course on find to use find. I hate this. And when I need it in a year time, I will have forgotten.
The man page has some examples, and there are also examples in the TexInfo manual which is also available here: https://www.gnu.org/software/findutils/manual/find.html If you have some hints how to make the manual more clear, then I'm open for suggestions. I know find(1) is not the easiest tool to use, but it is a very old tool and has to adhere to the specification [1], so not much can change as a GNU extension. Still, I believe that users can accommodate to the way find(1) is working: the tool internally builds a boolean expression tree with AND and OR logic. The option '-D tree' shows that expression (search for "Optimized command line" in the output). The point is that it always implicitly inserts -and when no other logical operator is given between subexpressions. Your above example makes (stripped off by more details from '-D tree'): ( ( ( ( ( ( ( -type d -a ( -not -readable ) ) -a -prune ) -a -path ./.dosemu ) -a -prune ) \ -a -path ./.cache ) -a -prune ) -o ( -name *.png -a -newermt -newermt ) ) -a -print You see that the -prune's are nested with ANDs instead of OR-ed. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html Have a nice day, Berny