That old chestnut - the shonky find command, again

OK - so I had a folder full of zip files and subfolders - but - I only wanted to copy the folders to destination :

find . -type d -exec cp -r {} $DEST \;

But FFS - I think find finds, and treats “.” ($PWD) as a found item and just copies everything…

I KINDA HATE the find command - it’s powerful - but it’s a clunker and long overdue for a replacement - I’ve read about potential replacements - and tried a couple, but despite find’s obvious limitations, I keep going back to it (at least you will find it nearly everywhere, even if on Solaris you can’t “iname” [that’s right NO case insenstivie filename search in Solaris! WTF?])

And all it means, if find finds $PWD when I search “.” in $PWD, and treats “-d” to mean EVERYTHING anyway - I can always wait for the POS to finish, cd to $DEST and delete the files (they’re all *.zip thankfully) - another option might be using the find command “find . -maxdepth 1 -type f -exec rm {} \;” - I live in the shell… but it still annoys the crap out of me from time to time… :smiley: :heart: but imagine if we were forced to use PowerShell :smiley: :smiley: :smiley: doesn’t bear consideration…

I assume you looked at fd
The package is called fd-find

I never use find or any alternative… just look at ls outputs, sometimes with globs.

Most of my searches are for the content of files, not their names… for that grep is excellent

1 Like

Annoyingly - installing the “fd” package (I must have installed it ages ago but not used it) doesn’t go into a folder that’s part of a known search path - i.e. I had to add /usr/lib/cargo/bin to my profile (.zshrc)…

Simple enough… But making it tricky to use the thing, or even FIND :smiley: it - is not exactly helpful to new users…

╭─x@titan ~/MPZ/LordDying  
╰─➤  ls -al
total 2016561
drwxrwxr-x   6 x family         11 Oct  7 10:06 .
drwxrwxr-x 887 x family        908 Oct  7 02:33 ..
drwxrwxr-x   3 x family         14 Oct  7 10:12 2013-SummonTheFaithless-FLAC
-rwxrwxr-x   1 x family  126464300 Oct  6 15:12 2013-SummonTheFaithless-FLAC.zip
drwxrwxr-x   3 x family         13 Oct  7 10:12 2015-PoisonedAltars-FLAC
-rwxrwxr-x   1 x family  259782636 Oct  6 15:12 2015-PoisonedAltars-FLAC.zip
drwxrwxr-x   3 x family         15 Oct  7 10:12 2019-MysteriumTremendum-FLAC
-rwxrwxr-x   1 x family 1153489887 Feb  4  2023 2019-MysteriumTremendum-FLAC.zip
-rwxrwxr-x   1 x family  133821502 Feb  4  2023 2019-MysteriumTremendum-mp3.zip
-rwxrwxr-x   1 x family  391334767 Oct  6 15:12 2024-ClandestineTrancendence-FLAC-pre-release.zip
drwxrwxr-x   3 x family          5 Oct  7 10:12 2024-ClandestineTrancendence-pre-release-FLAC
╭─x@titan ~/MPZ/LordDying  
╰─➤  fd -t d -x cp -r {} ~/Music/LordDying/.
╭─x@titan ~/MPZ/LordDying  
╰─➤  cd ~/Music/LordDying 
╭─x@titan ~/Music/LordDying  
╰─➤  ls -al
total 28
drwxrwxr-x   7 x x 4096 Oct  7 10:16 .
drwxrwxr-x 126 x x 4096 Oct  5 15:17 ..
drwxrwxr-x   3 x x 4096 Oct  7 10:16 2013-SummonTheFaithless-FLAC
drwxrwxr-x   3 x x 4096 Oct  7 10:16 2015-PoisonedAltars-FLAC
drwxrwxr-x   3 x x 4096 Oct  7 10:16 2019-MysteriumTremendum-FLAC
drwxrwxr-x   3 x x 4096 Oct  7 10:16 2024-ClandestineTrancendence-pre-release-FLAC
drwxrwxr-x   2 x x 4096 Oct  7 10:16 LordDying

for some reason, it creates an empty folder with the name of the source folder (i.e. “.”) - so while it skips the zip files - I still need to do some trivial housekeeping (cd ~/Music/LordDying ; rmdir LordDying [yes - it’s empty]).

But I may further investigate using “fd” eschewing “find” on my local systems - but will continue to maintain my knowledge and familiarity with legacy “find” command as some 95% + of the systems I manage probably won’t let me install stuff (and probably rightly so) from outside the vendor’s package management system (I’m pointing the finger squarely at Red Hat) - and CRINGE violently each time I’m forced to use Solaris’ clunky “UNIX” version of find (which can only do CASE SENSITVE filename search!).

You mean it WRITES on your filesystem?
I do not like that
It is supposed to do its work and lezve things alone.

Yes - in the place (destination) where I’m using “-X” to copy stuff to - one thing I like and appreciate with the fd command is that you don’t have to terminate / escape the "-exec" command with “\;” - which I invariably forget to do, nearly everytime! Like just a minute ago… I do that all the time - along with forgetting to “ssh hostname” argument to sshpass (why not just assume “ssh” anyway?).

1 Like

Yes, this is true, it exists nearly everywhere, but occasionally, the versions are incompatible between each other.

This is consequent and correct behavior and also correct, as ‘.’ is a directory.
To omit the $PWD, you could use my suggestion below.

$ find . -maxdepth 1 -type d ! -name '.'
1 Like

Just hit another thing that grinds my gears about the find command - “prune” like seriously WTF?

I want you to search, but ignore these folders - it’s devilishly impossible to do anything - I usually give up - e.g. on some system running some RPM based distro - I want to know which dir is eating all my disk (and no - install fd-find is NOT an option) - but it keeps trying to traverse /proc and /dev, and I don’t care about those two - and to make matters worse - on these clunky RPM based distros - these two arguments to find “-xdev” and “-mount” DON’T ACTUALLY do anything!

So - I end up having to run it on EVERYTHING anyway…

And I can’t find the culprit anyway - it’s a phantom… Something is eating “/” - or - causing it to miscalculate / misreport usage - there’s no files in “/” over 128 MB in size, /usr and /var are both under 3 GB in reported use, /home is under 1 GB, /root is like 300 k…

Started off with a /var/log/lastlog reporting 160 GB in size (despite the “/” filesystem being only 40 GB!) - I’ve wiped it several times - when I "ls -als /var/log/lastlog when it’s showing as 160 GB, it’s really only 16 k)…

I don’t normally recommend this - but - I did it - gave it a kick in the guts - and it’s come back up again and still misreporting in “df -h /” - doing some basic arithmetic - I can only see about < 5 GB being used on “/”

I downloaded x86_64 binary of ncdu and ran it (omitted the top line i.e. redacted “######” - but it’s on a separate filesystem anyway) :

ncdu 2.3 ~ Use the arrow keys to navigate, press ? for help
--- / -------------------------------------------------------------------------------------------------------------------------------------------------
   95.4 GiB [#####################] REDACTED
    2.4 GiB [                     ] /usr
    2.3 GiB [                     ] /var
  252.9 MiB [                     ] /boot
   52.4 MiB [                     ] /etc
   11.6 MiB [                     ] /run
    6.9 MiB [                     ] /home
  308.0 KiB [                     ] /root
   52.0 KiB [                     ] /tmp
e  16.0 KiB [                     ] /lost+found
e   4.0 KiB [                     ] /srv
e   4.0 KiB [                     ] /opt
e   4.0 KiB [                     ] /mnt
e   4.0 KiB [                     ] /media
    0.0   B [                     ] /proc
    0.0   B [                     ] /sys
    0.0   B [                     ] /dev
@   0.0   B [                     ]  lib64
@   0.0   B [                     ]  sbin
@   0.0   B [                     ]  lib
@   0.0   B [                     ]  bin
    0.0   B [                     ]  .autorelabel

But :

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/ol-root   40G   35G  3.1G  92%

Is there anything wrong with the original du -s *

1 Like

Yeah - I already did that… but “ncdu” does a better job…

But it’s not conclusive… I usually go something like :

du -d 1 -s (“-d 1” is depth = 1)… But that still crosses mountpoints…

1 Like