On Mon, 6 Mar 2023 12:08:00 +0100, "Carlos E. R."
So maybe this:
cer@Telcontar:~> find . -path ./.dosemu -path /.cache -prune -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied'
No, I see lots of:
./.cache/thumbnails/normal/c7dba33a30402263a4b13b42e37dcdd3.png ./.cache/thumbnails/normal/ad349eb75f1544c110bef048d1863dee.png ./.cache/thumbnails/normal/942fb32737e09f77a35fcbf77a6195cd.png
cer@Telcontar:~> find . -path ./.dosemu -prune -path ./.cache -prune -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied'
Nah, same problem. Only one -prune is working.
Maybe:
cer@Telcontar:~> find . -type d -not -readable -prune -path ./.dosemu -prune -path ./.cache -prune -o -name "*.png" -newermt 2023-01-01
No:
./.cache/thumbnails/normal/91f916ae750a5dca8f2020fb68648166.png ./.cache/thumbnails/normal/028af4e97867a90eb4551b5be73a1e30.png ./.cache/thumbnails/normal/bd6057d9fa3d308ad94a610aa1f185c3.png ^C
'find' includes an implicit "and" operator (-a) between every pair of terms in the expression. In your first find above, the adjacent -path terms, "-path ./.dosemu" and "-path /.cache", are never both true for the same file or directory as find traverses the tree, and therefore the 'and' of the pair will always be false, and the -prune which follows them will never be invoked. The same situation exists with the other two find commands. It looks like you could fix those by just adding a '-o' after each -prune that isn't already followed by one. For the first one, try: (missing dot for the cache path added) find . \( -path ./.dosemu -o -path ./.cache \) -prune \ -o -name "*.png" -newermt 2023-01-01 -- Robert Webb