8:07 Just checked the man page, and “+” means “greater than”, not “at least”. Similarly “-” means “less than”, not “at most”. Also k is kibibytes, not kilobytes, and M is mebibytes, not megabytes. And the sizes are rounded to the specified unit. Thus, “-10M” will only match files up to 9 × 1048576 = 9437184 bytes in size, not 10 × 1048576 - 1 = 10485759 bytes as you might have been expecting.
locate - searches a pre-made files database of the filesystem (hence updatedb to update the database beforehand) find - makes an actual live search on the filesystem (slow on big harddrives)
One common idiom is feeding a list of files from find to some other command using xargs: find «criteria» -print | xargs «cmd» When feeding file names to another shell command, beware of shell-specials, for example spaces in filenames. Don’t forget you can also have newlines in filenames. The GNU versions of find and xargs have the option to use nulls as pathname separators, which avoids this problem: find «criteria» -print0 | xargs -0 «cmd»
Thank you, Derek. These great CLI tools, including man pages are why I have no problem with those who insist on saying "Gnu-Linux". I pronounce the "Gnu" silently but I do always remember it. And always have time for material on the original Unix toolset.
What is the equivalent on Linux distros for the software you can install on Windows called "Everything",which is the ultimate instantaneous file search app?
Finding duplicate files is easy - and there's several apps for that. But I'm looking for an app or script that will sort things in such a way that any pairs of directories with a large number of identical files are easily identified. Say I've got a directory of music, and an album got located in a number of places - but some copies of the album have extra tracks that the others don't (Japan release vs. US release, or some such...)
usually what i do is execute a command afterward like find all ogg files and convert them to mp3 with ffmpeg. but for that i have a script cause i dont memorize that command...
hey derek i have been following the channel for a while and i see that you have an opinion on many programs that are out there (various terminals, filemanagers, mediaplayers, texteditors...). so have you heard of emelfm2 what are your thoughts on it or would you try it some day?
2:09 And you can do a case-insensitive search with -iname instead of -name. Useful if you have files transferred from other systems that end up with uppercase names (e.g. .TXT instead of .txt).
wow, thank a lot. "CTRL + L" is a hidden treasure.
4 роки тому+2
Ctrl+L is different from the clear command. The clear command actually clears the screen and displays the prompt on the first line. Ctrl+L scrolls the terminal window so that the prompt is on the first line.
How much files you have in locate index? Is it efficient when encountering >8mil files? Btw nice video. Keep it going to introduce linux fundamentals :)
The find command is probably the worst of all Unix tools. It is too bloated, does so many things that have little to do with finding stuff, thus being contrary to Unix philosophy. And it has terrible, inconsistent syntax. Why is "-name" not "-n" or "--name"?
The find executable on my 64-bit system is just about 300K in size. What do you _not_ consider “bloated”?
4 роки тому+1
@@lawrencedoliveiro9104 It's not the size that makes a program bloated. It's the features. Also, btw, 300k is huge for what this program does (finds files), this is almost three times as big as a complete terminal emulator st (which is about 110k). A Unix program ought to do one thing and do it well. There are no features in it that are not absolutely necessary for that one thing the program does. If there is a need for a feature that is beyond the one thing the program does, a different program is made. You don't cram features into programs, that's bloat. The find program needs to do one thing: find files. It does not need to do anything else. But no, it is bloated with features most users will need maybe once in their life, probably even less. Look at the man page for find: a manual for a program that is supposed to find files is 10746 words long (this is for GNU findutils 4.7.0). To put it into perspective, the manual for find is as big as a complete terminal emulator (the program). That is what bloat is. A command for finding files should not need more than a hundred words in its manual. It should have only one feature: finding files, and that it should do quickly and correctly.
linux is not a mess it is thoughtful and consistent int that EVERYTHING is a file so why should there be anything special for drives? drives are files.
I love how you get straight to useful content.
“Read the man page for find”
.
.
.
.
.
.
.
.
.
.
.
“You’re not gonna want to read that gigantic novel of a man page...”
🤣
ldo@theon:~> man find | wc -l
1277
But it’s handy for looking up things as I need them.
8:07 Just checked the man page, and “+” means “greater than”, not “at least”. Similarly “-” means “less than”, not “at most”. Also k is kibibytes, not kilobytes, and M is mebibytes, not megabytes. And the sizes are rounded to the specified unit. Thus, “-10M” will only match files up to 9 × 1048576 = 9437184 bytes in size, not 10 × 1048576 - 1 = 10485759 bytes as you might have been expecting.
locate - searches a pre-made files database of the filesystem (hence updatedb to update the database beforehand)
find - makes an actual live search on the filesystem (slow on big harddrives)
One common idiom is feeding a list of files from find to some other command using xargs:
find «criteria» -print | xargs «cmd»
When feeding file names to another shell command, beware of shell-specials, for example spaces in filenames. Don’t forget you can also have newlines in filenames. The GNU versions of find and xargs have the option to use nulls as pathname separators, which avoids this problem:
find «criteria» -print0 | xargs -0 «cmd»
Thank you, Derek. These great CLI tools, including man pages are why I have no problem with those who insist on saying "Gnu-Linux". I pronounce the "Gnu" silently but I do always remember it. And always have time for material on the original Unix toolset.
Derek, updatedb is usually automatically updated with a cron job on a daily basis.
Very good tutorial about FISH. Thank You!
What is the fish theme and color scheme you're using ?
What is the equivalent on Linux distros for the software you can install on Windows called "Everything",which is the ultimate instantaneous file search app?
How to use SBCL like shell ?
Hey Derek, the find manpage is a perfect example why manpages suck. Take a look at tldr
I sincerely hope you are not a fan of GNU info ...
@@lawrencedoliveiro9104 Guess why I mentioned tldr
Finding duplicate files is easy - and there's several apps for that. But I'm looking for an app or script that will sort things in such a way that any pairs of directories with a large number of identical files are easily identified. Say I've got a directory of music, and an album got located in a number of places - but some copies of the album have extra tracks that the others don't (Japan release vs. US release, or some such...)
Hello from France !!! Thanks for your amazing videos Derek ! Keep this great work ! btw, I use Arch (... from Manjaro)
'find' is good to know but I prefer more minimal syntax of 'fd'
This reminds me of Computer Basics (Chapter 6: Finding Files, Pages 153-180).
something's wrong with your man pages
usually what i do is execute a command afterward like find all ogg files and convert them to mp3 with ffmpeg. but for that i have a script cause i dont memorize that command...
hey derek i have been following the channel for a while and i see that you have an opinion on many programs that are out there (various terminals, filemanagers, mediaplayers, texteditors...). so have you heard of emelfm2 what are your thoughts on it or would you try it some day?
2:09 And you can do a case-insensitive search with -iname instead of -name. Useful if you have files transferred from other systems that end up with uppercase names (e.g. .TXT instead of .txt).
6:57 Ah, OK.
A faster way to find insecure files in your system:
$ insecure='-delete'; sudo find / $insecure
Wow! Now I can locate or find all those Awesome files I can't find... What a relief.... Thanks DT
LLAP
When they say RTFM but the manual is way too long
Thus man pages. Or the Arch Wiki.
1) I use Ctrl+L instead of typing "clear"
2) "apt install locate" for lazy people like me =))
wow, thank a lot. "CTRL + L" is a hidden treasure.
Ctrl+L is different from the clear command. The clear command actually clears the screen and displays the prompt on the first line. Ctrl+L scrolls the terminal window so that the prompt is on the first line.
gnu utils have the best man pages
Hey whatever happened to doas?
He aliased it as sudo.
Glad i....found....this video 😏
...or just use fzf :P
Indeed, fzf way better.
Do a video on how to find TP. You will have 1 million subscribers by Sunday.
"I don't know your name... I don't know where you are... But I will find you!" 😃
Edit: perfect name for an application for indexing files - "Taken"
How much files you have in locate index? Is it efficient when encountering >8mil files?
Btw nice video. Keep it going to introduce linux fundamentals :)
install the program called "tldr" to get a quick list of the most important commands for a given program
Second! :)
The find command is probably the worst of all Unix tools. It is too bloated, does so many things that have little to do with finding stuff, thus being contrary to Unix philosophy. And it has terrible, inconsistent syntax. Why is "-name" not "-n" or "--name"?
gnu is not Unix, why would they care about the Unix philosophy?
find is a Unix utility. I am not necessarily talking about GNU find, even though everything I say about find applies to GNU find, as well.
The find executable on my 64-bit system is just about 300K in size. What do you _not_ consider “bloated”?
@@lawrencedoliveiro9104 It's not the size that makes a program bloated. It's the features. Also, btw, 300k is huge for what this program does (finds files), this is almost three times as big as a complete terminal emulator st (which is about 110k).
A Unix program ought to do one thing and do it well. There are no features in it that are not absolutely necessary for that one thing the program does. If there is a need for a feature that is beyond the one thing the program does, a different program is made. You don't cram features into programs, that's bloat.
The find program needs to do one thing: find files. It does not need to do anything else. But no, it is bloated with features most users will need maybe once in their life, probably even less.
Look at the man page for find: a manual for a program that is supposed to find files is 10746 words long (this is for GNU findutils 4.7.0). To put it into perspective, the manual for find is as big as a complete terminal emulator (the program). That is what bloat is. A command for finding files should not need more than a hundred words in its manual. It should have only one feature: finding files, and that it should do quickly and correctly.
@ So what features would you remove from find, and where else can you find them?
Linux is a mess: there are no disks C:, D:, E, no Program Files, why everything should be so cryptic?
RTFM
Those cryptic disks under Windows are simply files under /dev on Linux : )
disks are usually in /media or /mnt
@@NapanTR Yup, after mounting ; )
linux is not a mess it is thoughtful and consistent int that EVERYTHING is a file so why should there be anything special for drives? drives are files.