-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I trying to find png files created recently in my home. So I do: cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01 find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate Basic/Seagate’: Permission denied p.png cer@Telcontar:~> Can I make it not print the error? If I try: find -L . -name "*.png" -newermt 2023-01-01 there are so many errors that I can not read the results. - -ignore_readdir_race doesn't do it. cer@Telcontar:~> find -L . -name "*.png" -path ./.dosemu/ -prune -ignore_readdir_race -newermt 2023-01-01 ind: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-upower.service-y7EoBi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-rtkit-daemon.service-2odVpf’: Permission denied find: ‘./.dosemu/drives/d/tmp/BootInfo-JQ12X6Q3’: Permission denied find: ‘./.dosemu/drives/d/tmp/BootInfo-bzvrn7Gi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-power-profiles-daemon.service-UnAvYi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-geoclue.service-aQ0lfj’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-ntpd.service-Mr8llh’: Permission denied ^C Prune is not working. Of course I know I'm doing it wrong, but man doesn't say how to do it: -prune True; if the file is a directory, do not descend into it. If -depth is given, then -prune has no effect. Be- cause -delete implies -depth, you can- not usefully use -prune and -delete together. For example, to skip the directory src/emacs and all files and directories under it, and print the names of the other files found, do something like this: find . -path ./src/emacs -prune -o -print That's all it says, and no more examples. - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY/5KoBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVPGUAn1vQdZOD+mlK4YrHtFLp pJyObyQUAJ94m76QZiFjZhQ9y52HGMhB1Odcsg== =s+fF -----END PGP SIGNATURE-----
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Feb 2023 19:40:32 +0100 (CET) . . . Can I make it not print the error? If I try: find -L . -name "*.png" -newermt 2023-01-01 there are so many errors that I can not read the results. "find -L . -name "*.png" -newermt 2023-01-01 2>/dev/null" -- Bob Rogers http://www.rgrjr.com/
On 2023-02-28 20:09, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Feb 2023 19:40:32 +0100 (CET)
. . .
Can I make it not print the error?
If I try:
find -L . -name "*.png" -newermt 2023-01-01
there are so many errors that I can not read the results.
"find -L . -name "*.png" -newermt 2023-01-01 2>/dev/null"
huh, I thought of that, but I assumed there would be some obscure option :-} -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01
I would probably do this: find . -type f -name \*.png -newermt 2023-01-01
find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate Basic/Seagate’: Permission denied p.png cer@Telcontar:~>
Can I make it not print the error?
you could add "2>/dev/null" -- Per Jessen, Zürich (-0.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-02-28 a las 19:40 +0100, Carlos E. R. escribió:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01 find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate find: Basic/Seagate’: Permission denied p.png cer@Telcontar:~>
Found a way to do it with 'mc' If I tell 'mc' to find all *png files in home, following links, it takes hours. Literally, I had to abort after two hours. Apparently the .wine directory lists the entire root. Then I noticed that it has an "ignore" entry. This works: Left File Command Options Right ┌<─ ~ ─────────────... │.n ... ┌────────────────────────── Find File ───────────────────────────┐ │/.. ... │ Start at: │ │/.AbiSuite ... │ . [^] [ Tree ] │ │/.Heaven ... │ [x] Enable ignore directories: │ │/.Sayonara ... │ .wine:.thumbnails:.cache [^] │ │/.SearchAndRescue ... ├────────────────────────────────────────────────────────────────┤ │/.Skype ... │ File name: Content: │ │/.WebSigner ... │ *png [^] [^] │ │/.acrobat ... │ [x] Find recursively [ ] Whole words │ │/.adobe ... │ [x] Follow symlinks [ ] Regular expression │ │/.afirma ... │ [x] Using shell patterns [ ] Case sensitive │ │/.afirma.antiguo ... │ [ ] Case sensitive [ ] All charsets │ │/.alpine-smime ... │ [ ] All charsets [ ] First hit │ ├──────────────────... │ [ ] Skip hidden │ │UP--DIR ... ├────────────────────────────────────────────────────────────────┤ └──────────────────... │ [< OK >] [ Cancel ] │ Hint: Want your pla... └────────────────────────────────────────────────────────────────┘ cer@Telcontar:~> This finds 54525 files in a few seconds. I just have then to panelize and sort by date, then hit "enter" on the candidates to see which is the photo I'm searching for. (still failed to find the photo I was searching for. Maybe it is jpg, or pdf. Working on it) - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY/5VRRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVOtUAnioBAm5xtxy3IrfSoOUK 8o9/dZy1AJ9bsU5qRK6ZFgOO36bj8DDmM+Y1BA== =hIIf -----END PGP SIGNATURE-----
Am 28.02.23 um 20:25 schrieb Carlos E. R.:
El 2023-02-28 a las 19:40 +0100, Carlos E. R. escribió:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01 find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate find: Basic/Seagate’: Permission denied p.png cer@Telcontar:~>
Found a way to do it with 'mc'
If I tell 'mc' to find all *png files in home, following links, it takes hours. Literally, I had to abort after two hours. Apparently the .wine directory lists the entire root.
Then I noticed that it has an "ignore" entry. This works:
Left File Command Options Right ┌<─ ~ ─────────────... │.n ... ┌────────────────────────── Find File ───────────────────────────┐ │/.. ... │ Start at: │ │/.AbiSuite ... │ . [^] [ Tree ] │ │/.Heaven ... │ [x] Enable ignore directories: │ │/.Sayonara ... │ .wine:.thumbnails:.cache [^] │ │/.SearchAndRescue ... ├────────────────────────────────────────────────────────────────┤ │/.Skype ... │ File name: Content: │ │/.WebSigner ... │ *png [^] [^] │ │/.acrobat ... │ [x] Find recursively [ ] Whole words │ │/.adobe ... │ [x] Follow symlinks [ ] Regular expression │ │/.afirma ... │ [x] Using shell patterns [ ] Case sensitive │ │/.afirma.antiguo ... │ [ ] Case sensitive [ ] All charsets │ │/.alpine-smime ... │ [ ] All charsets [ ] First hit │ ├──────────────────... │ [ ] Skip hidden │ │UP--DIR ... ├────────────────────────────────────────────────────────────────┤ └──────────────────... │ [< OK >] [ Cancel ] │ Hint: Want your pla... └────────────────────────────────────────────────────────────────┘ cer@Telcontar:~>
This finds 54525 files in a few seconds. I just have then to panelize and sort by date, then hit "enter" on the candidates to see which is the photo I'm searching for.
(still failed to find the photo I was searching for. Maybe it is jpg, or pdf. Working on it)
-- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
Wow, never recognized the "ignore directory's" simoN -- www.becherer.de ----------------------------------------------- - Das ist die vorlaeufig endgueltige Version! - Herbert C. Maier Dipl.-Ing. (FH) -----------------------------------------------
On 2023-02-28 20:38, Simon Becherer wrote:
Am 28.02.23 um 20:25 schrieb Carlos E. R.:
El 2023-02-28 a las 19:40 +0100, Carlos E. R. escribió:
I trying to find png files created recently in my home. So I do:
...
Found a way to do it with 'mc'
If I tell 'mc' to find all *png files in home, following links, it takes hours. Literally, I had to abort after two hours. Apparently the .wine directory lists the entire root.
Then I noticed that it has an "ignore" entry. This works:
...
Wow, never recognized the "ignore directory's"
Yeah, me neither :-D I'm still looking to find where the "date range" is hidden, but no luck so far ;-) Then I would tell it to grep for some string in files from the last 3 months. Maybe I have the file in another computer :-} (it is a photo or pdf of my old router config) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, 28 Feb 2023 19:40:32 +0100 (CET), "Carlos E. R." <robin.listas@telefonica.net> wrote:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01 find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate Basic/Seagate’: Permission denied p.png
Can I make it not print the error?
'sudo find'
If I try:
find -L . -name "*.png" -newermt 2023-01-01
there are so many errors that I can not read the results.
'find' following symlinks (-L option) is a big mess.
- -ignore_readdir_race doesn't do it.
You are not deleting files, so -ignore_readdir_race has no use for you.
cer@Telcontar:~> find -L . -name "*.png" -path ./.dosemu/ -prune -ignore_readdir_race -newermt 2023-01-01
ind: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-upower.service-y7EoBi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-rtkit-daemon.service-2odVpf’: Permission denied find: ‘./.dosemu/drives/d/tmp/BootInfo-JQ12X6Q3’: Permission denied find: ‘./.dosemu/drives/d/tmp/BootInfo-bzvrn7Gi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-power-profiles-daemon.service-UnAvYi’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-geoclue.service-aQ0lfj’: Permission denied find: ‘./.dosemu/drives/d/tmp/systemd-private-2d6e8e36b0594f8bbdd30cba975d2743-ntpd.service-Mr8llh’: Permission denied ^C
The -path term will never match the slash on the end, so this will produce no result: find . -path ./.dosemu/ 2>/dev/null Try: find . -path ./.dosemu -prune -o \ -name "router_config_i_will_need_in_the_future.png" -newermt 2023-01-01 -print -- Robert Webb
On 2/28/23 19:40, Carlos E. R. wrote:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01
________________________^ That's ambiguous in the case you have files which begin with a '-'; find would treat it as option. Better either use '.', or leave it out completely (dot '.' is the implicit default).
find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate Basic/Seagate’: Permission denied p.png cer@Telcontar:~>
Can I make it not print the error?
no, find(1) does not have an option to suppress this. The others already suggested 2>/dev/null. Obviously, this also swallows other error diagnostics. find / -xdev -type d -not -readable -prune -o -mtime -1 -ls
Prune is not working. Of course I know I'm doing it wrong, but man doesn't say how to do it:
-prune True; if the file is a directory, do not descend into it. If -depth is given, then -prune has no effect. Be- cause -delete implies -depth, you can- not usefully use -prune and -delete together. For example, to skip the directory src/emacs and all files and directories under it, and print the names of the other files found, do something like this: find . -path ./src/emacs -prune -o -print
That's all it says, and no more examples.
There's an example section "Pruning - omitting files and subdirectories" in the find(1) man page, and also the Texinfo manual [1] has examples. [1] https://www.gnu.org/software/findutils/manual/find.html Your example with -prune would be: $ find -type d -not -readable -prune -o -name '*.png' -newermt 2023-01-01 (Mind the '-o' option - look into the manual why this is needed.) Have fun, Berny
On 2023-03-04 10:00, Bernhard Voelker wrote:
On 2/28/23 19:40, Carlos E. R. wrote:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01
________________________^ That's ambiguous in the case you have files which begin with a '-'; find would treat it as option. Better either use '.', or leave it out completely (dot '.' is the implicit default).
Yes, I tried both. Initially I started with dot. I tried * intentionally to give the list of directories that are symlinks.
find: ‘Backups Discos/Disco Seagate Basic 2TB para backup de Legolas/Seagate Basic/Seagate’: Permission denied p.png cer@Telcontar:~>
Can I make it not print the error?
no, find(1) does not have an option to suppress this.
The others already suggested 2>/dev/null. Obviously, this also swallows other error diagnostics.
Obviously. Any important error is also swallowed in the thousands permission denied.
find / -xdev -type d -not -readable -prune -o -mtime -1 -ls
Prune is not working. Of course I know I'm doing it wrong, but man doesn't say how to do it:
-prune True; if the file is a directory, do not descend into it. If -depth is given, then -prune has no effect. Be- cause -delete implies -depth, you can- not usefully use -prune and -delete together. For example, to skip the directory src/emacs and all files and directories under it, and print the names of the other files found, do something like this: find . -path ./src/emacs -prune -o -print
That's all it says, and no more examples.
There's an example section "Pruning - omitting files and subdirectories" in the find(1) man page, and also the Texinfo manual [1] has examples.
[1] https://www.gnu.org/software/findutils/manual/find.html
Your example with -prune would be:
$ find -type d -not -readable -prune -o -name '*.png' -newermt 2023-01-01
(Mind the '-o' option - look into the manual why this is needed.)
Have fun, Berny
Heh. I never find find too much fun ;-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-04 03:30:12 Carlos E. R. wrote:
On 2023-03-04 10:00, Bernhard Voelker wrote:
On 2/28/23 19:40, Carlos E. R. wrote: [snip] no, find(1) does not have an option to suppress this.
The others already suggested 2>/dev/null. Obviously, this also swallows other error diagnostics.
Obviously. Any important error is also swallowed in the thousands permission denied.
grep -v 'permission denied' [snip] Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On 2023-03-04 21:48, J Leslie Turriff wrote:
On 2023-03-04 03:30:12 Carlos E. R. wrote:
On 2023-03-04 10:00, Bernhard Voelker wrote:
On 2/28/23 19:40, Carlos E. R. wrote: [snip] no, find(1) does not have an option to suppress this.
The others already suggested 2>/dev/null. Obviously, this also swallows other error diagnostics.
Obviously. Any important error is also swallowed in the thousands permission denied.
grep -v 'permission denied' [snip]
Of course, I should have remembered. But wait, a pipe (|) might not work, because it goes on the standard error output. So it would be: find -L . -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied' This gets a lot of: /.cache/thumbnails/normal/47ba6e76124f62d4035dfed3d7f541f8.png ./.cache/thumbnails/normal/b20a108af8a28eeb0bb5f03bbac84353.png ./.cache/thumbnails/normal/91f916ae750a5dca8f2020fb68648166.png ./.cache/thumbnails/normal/028af4e97867a90eb4551b5be73a1e30.png ./.cache/thumbnails/normal/bd6057d9fa3d308ad94a610aa1f185c3.png ./.dosemu/drives/d/tmp/tclipboard.png ./.dosemu/drives/d/tmp/Screenshot_2023-01-06_22-25-19.png ./.dosemu/drives/d/tmp/Screenshot_2023-01-06_22-26-18.png ./.dosemu/drives/d/tmp/Screenshot_2023-01-06_22-32-54.png ./.dosemu/drives/d/tmp/Screenshot_2023-01-06_22-34-12.png 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 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. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-06 05:08:00 Carlos E. R. wrote:
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.
Heh, yeah. I gave up on find when I was running OpenSuSE 6.3; it's probably not hard to use, but the man file is pretty useless for learning to use it. I use tree a lot, together with less and grep (sometimes three or four greps are necessary :-) ) and I find it much more friendly (though it would be better if the options, when requested, were to the left of the tree symbols instead of to the right of them). Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On Mon, 6 Mar 2023 12:08:00 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-03-08 a las 03:25 -0000, Robert Webb escribió:
On Mon, 6 Mar 2023 12:08:00 +0100, "Carlos E. R." <> wrote:
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.
Ahhhh... I see.
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
This works: cer@Telcontar:~> find . \( -path ./.dosemu -o -path ./.cache \) -prune -o -name "*.jpg" -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied' but produces a lot of entries I do not want: ./.wine/drive_c/users/cer/Application Data/Foxit Software/Foxit Reader/StartPage/Start/en_us/Default/show_con_bg.jpg ./.wine/drive_c/users/cer/Application Data/Foxit Software/Foxit Reader/StartPage/Start/en_us/Default/history_winbg.jpg ./.wine/drive_c/users/cer/Application Data/Foxit Software/Foxit Reader/StartPage/Start/en_us/Default/content_showbg.jpg So I try to prune them. I do: cer@Telcontar:~> find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine \) -prune -o -name "*.jpg" -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied' ... ./.kodi/userdata/Thumbnails/3/3e507be4.jpg ./.kodi/userdata/Thumbnails/3/359a058f.jpg ./.kodi/userdata/Thumbnails/3/309b63d8.jpg ./.kodi/userdata/Thumbnails/3/308b6caa.jpg Ok, again. cer@Telcontar:~> find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine -o -path ./.kodi \) -prune -o -name "*.jpg" -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied' | less -S ... ./Fotos Eclipse/DSC_5861.jpg ./Fotos Eclipse/DSC_5786.jpg ./Fotos Eclipse/DSC_5893.jpg That can not be. cer@Telcontar:~> l ./Fotos\ Eclipse/DSC_5861.jpg -rw-r--r-- 1 cer users 559598 Jul 28 2018 ./Fotos Eclipse/DSC_5861.jpg cer@Telcontar:~> cer@Telcontar:~> stat ./Fotos\ Eclipse/DSC_5861.jpg File: ./Fotos Eclipse/DSC_5861.jpg Size: 559598 Blocks: 1096 IO Block: 4096 regular file Device: 805h/2053d Inode: 2889284 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users) Access: 2022-10-21 11:41:37.594823655 +0200 Modify: 2018-07-28 13:57:08.747107912 +0200 Change: 2018-07-28 13:57:08.747107912 +0200 Birth: 2018-07-28 13:57:08.559115330 +0200 cer@Telcontar:~> How come? It is ignoring the "-newermt 2023-01-01" part. Baffled again :-??? - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZAjsABwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVg+sAniNk9FFZ7sgyzijBkkMs RKPPr0HVAJ9giu08Dbc1n8AjwzmYCQKacH3AJw== =bGle -----END PGP SIGNATURE-----
On Wed, 8 Mar 2023 21:11:44 +0100 (CET), "Carlos E. R." <robin.listas@telefonica.net> wrote:
El 2023-03-08 a las 03:25 -0000, Robert Webb escribió:
For the first one, try:
find . \( -path ./.dosemu -o -path ./.cache \) -prune \ -o -name "*.png" -newermt 2023-01-01
This works:
cer@Telcontar:~> find . \( -path ./.dosemu -o -path ./.cache \) -prune -o -name "*.jpg" -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied'
but produces a lot of entries I do not want: [...] Ok, again.
cer@Telcontar:~> find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine -o -path ./.kodi \) -prune -o -name "*.jpg" -o -name "*.png" -newermt 2023-01-01 2>&1 | grep -v 'Permission denied' | less -S ... ./Fotos Eclipse/DSC_5861.jpg ./Fotos Eclipse/DSC_5786.jpg ./Fotos Eclipse/DSC_5893.jpg
That can not be. [...] How come? It is ignoring the "-newermt 2023-01-01" part.
OK. My bad. Short answer: Add a -print to the sub-expression you want to see results from. I often forget this. 'find' defaults to printing the path of everything that evaluates true, according to the *whole* expression, unless you include a -print, or -exec, or something like that. This means that whatever you pruned, or intended to exclude by matching it with another or'ed sub-expression, still gets printed, by default. So: find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine \ -o -path ./.kodi \) -prune \ -o -name "*.jpg" \ -o -name "*.png" -newermt 2023-01-01 -print 2>&1 \ | grep -v 'Permission denied' | less -S -- Robert Webb
On 3/8/23 22:56, Robert Webb wrote:
So:
find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine \ -o -path ./.kodi \) -prune \ -o -name "*.jpg" \ -o -name "*.png" -newermt 2023-01-01 -print 2>&1 \ | grep -v 'Permission denied' | less -S
I didn't follow the thread in every detail, but the above looks like as if the two '-o name "..."' would have to be put into a bracket group. Otherwise find(1) would apply the -newermt and the action -print only to the PNGs. Indenting helps, too: find . \ \( -path ./.dosemu -o -path ./.cache -o -path ./.wine -o -path ./.kodi \) \ -prune -o \ \( -name "*.jpg" -o -name "*.png" \) \ -newermt 2023-01-01 \ -print 2>&1 \ | grep -v 'Permission denied' | less -S Have a nice day, Berny
On Thu, 9 Mar 2023 00:43:10 +0100, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 3/8/23 22:56, Robert Webb wrote:
So:
find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine \ -o -path ./.kodi \) -prune \ -o -name "*.jpg" \ -o -name "*.png" -newermt 2023-01-01 -print 2>&1 \ | grep -v 'Permission denied' | less -S
I didn't follow the thread in every detail, but the above looks like as if the two '-o name "..."' would have to be put into a bracket group. Otherwise find(1) would apply the -newermt and the action -print only to the PNGs.
Carlos' intent was in fact to exclude the "*.jpg" files because they were adding a lot of noise to the output. Unfortunately, when I added the -print to limit the output to just the PNG sub-expression, I didn't realize that the JPEG exclusion is superfluous. That line above can just be deleted. -- Robert Webb
On 3/10/23 02:38, Robert Webb wrote:
On Thu, 9 Mar 2023 00:43:10 +0100, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 3/8/23 22:56, Robert Webb wrote:
So:
find . \( -path ./.dosemu -o -path ./.cache -o -path ./.wine \ -o -path ./.kodi \) -prune \ -o -name "*.jpg" \ -o -name "*.png" -newermt 2023-01-01 -print 2>&1 \ | grep -v 'Permission denied' | less -S
I didn't follow the thread in every detail, but the above looks like as if the two '-o name "..."' would have to be put into a bracket group. Otherwise find(1) would apply the -newermt and the action -print only to the PNGs.
Carlos' intent was in fact to exclude the "*.jpg" files because they were adding a lot of noise to the output. Unfortunately, when I added the -print to limit the output to just the PNG sub-expression, I didn't realize that the JPEG exclusion is superfluous. That line above can just be deleted.
That explains it, thanks. Have a nice day, Berny
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
On Sat, 4 Mar 2023 10:30:12 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-03-04 10:00, Bernhard Voelker wrote:
On 2/28/23 19:40, Carlos E. R. wrote:
I trying to find png files created recently in my home. So I do:
cer@Telcontar:~> find * -name "*.png" -newermt 2023-01-01
________________________^ That's ambiguous in the case you have files which begin with a '-'; find would treat it as option. Better either use '.', or leave it out completely (dot '.' is the implicit default).
Yes, I tried both. Initially I started with dot. I tried * intentionally to give the list of directories that are symlinks.
* doesn't find directories that are symlinks because it doesn't put a / on the end of the directory name, which is what is required. find -L . is the proper way to do it. * also doesn't search directories whose name starts with a . whereas find . does.
participants (8)
-
Bernhard Voelker -
Bob Rogers -
Carlos E. R. -
Dave Howorth -
J Leslie Turriff -
Per Jessen -
Robert Webb -
Simon Becherer