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-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 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 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. 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

On Wed, 8 Mar 2023 21:11:44 +0100 (CET), "Carlos E. R." 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 Thu, 9 Mar 2023 00:43:10 +0100, Bernhard Voelker 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/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