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… but imagine if we were forced to use PowerShell doesn’t bear consideration…
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 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!).
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?).
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%