Some of you commenters are pointing out, accurately, that `grep` can recursively search files on its own, without `find`. Of course it can! But remember, grepping was just the example I was using to illustrate `-exec`. Your options between `-exec` and `{} +` are practically limitless. Also, to those of you about to voice your displeasure with "needing the terminal to find lost files", your assignment is this word problem: "Susie has a VPS running a web server, and her server daemon has crashed due to a malformed configuration file. How can Susie identify and resolve the problem using only GUI tools and no terminal commands?"
I'm a retired UNIX/Linux System Administrator (30+ years) and I find your content refreshing and more to the point very useful! Yeah there are newer and perhaps simpler commands, but knowing the basics is still very important. People would ask me why learn vi when there is nano for example. Because from AIX to (name your Linux distro) etc, you'll always have vi :) Thanks again for your hard work and keep keep doing what you're doing!
@@occamraiser Not quite sure how to handle this, but are you aware of the fact vim has more features than nano does? Of course, if you haven't taken the time to learn vim then you won't be aware of that fact and if the pitiful nano is all you need then it's fine. But it is shite for handling text files of any non-trivial degree of length or complexity.
mc (Midnight Commander) has been around for 30 years. Why people are still using find, vi, nano and so on? I understand that there are some cases when there's no other choice (for example, to run certain command with all the found files), but they are very rare.
Holy Crap! 30+ years in this business and I *just* learned about '+' as an argument to find. How much of my life have I wasted to \; ?! Thanks Veronica! You're frickin' awesome!
I prefer `find | xargs grep` because it executes grep one time across all the found files instead of executing a separate grep for each file as find -exec would do. find | xargs grep is often an order of magnitude faster when grepping a lot of files. EDIT: OK I wrote the above before I finished watching the video! And I see the the '+' form of exec does effectively the same thing. Wow I learned something new after using find daily for about 25 years. Thanks!
I want to mention GNU `parallel`, which is similar to `xargs` but distributes the load across all logical cores. The only bad thing is that it requires a Perl interpreter (and many other Perl dependencies)
the xarg approach is an antipattern: it's broken with filenames containing quotes or newlines. The cure is to use GNU's versions with the -print0 predicate to find, and the -0 (or --null) option to xarg. But this is not portable, and is very awkward. -exec (or even -execdir) with + is the correct approach
Thank you! Because honestly, even as a somewhat experienced Linux user, learning these types of tools is hard, because you only use it when you needed by looking at the long documentation, then you never touch it again so you forget. Then when you needed it once more, it's the same tedious process. A fun video like this is perfect to master a tool like this!
Started using Unix on a VAX 11/780 in the '80s before you were born!! But you're never too old to learn something new! Been using "\;" since then, and only just now learned about "+"! Thank you.
I've been a professional Linux sysadmin since the 90s and use the find command all the damn time. This intro was perfect, and it taught me something I didn't know - ending the command with a plus instead of a semicolon. That's super useful in many contexts - thanks for that!
I've been in "THE INDUSTRY" for about 8 years and I notice that: - I still desperately need these easy basic tutorials about the most fundamental commands - I "FIND" (wink, wink) it very calming when they're explained to me like a patient 8th grade substitute teacher would Keep them coming!
Linux has been my development platform for work for nearly a decade, but I still watch these videos because of how fun they are. And speaking of keeping up with the Commodore, I haven't written a BASIC program in years, I realised I miss it.
Seriously - you're doing "god's" work. All software engineers should know the Unix shell. Linux runs the internet. I can't tell you how many professional programmers I know who cannot use BASH. It baffles me. Keep doing what you do!
👍 for the “+” tip. If you need absolute paths use "`pwd`" instead of . And if you want one line per result use “find” a second time instead of “echo” find "`pwd`" -type f -exec find {} +
I love these videos -- if I ever have any kind of "virtual assistant" on a Linux machine, I want the voice to be Veronica Explains in 8th grade math teacher mode.
'cause the Commodore is keeping up with you! Loved how simple this was, and especially the explanation of the exec parameter termination and curly braces. I've seen so many "here's how you use find to ..." tutorials and never understood what was going on with those.
I need to try out a few examples tomorrow on my system, it's been awhile since I used this sequence of commands. I always used to use find then xargs then grep. Great timely video!
With 30+ years Unix experience I have to admit I never heard of + too. While quick, keep in mind there are limits for the size of a command line in many systems. Also, if you want to use the return value of -exec, + might not be handy. In situation like the one in in the video, I often use "grep * */* */*/* ... " as there are typically not more than 4 or 5 levels of directories. This does not need find, only the shell, that is one process less. If I get an error like "*/*/*/*/* not found" I know I added enough levels. I use this *ALL* the time. Also, I use fgrep when just looking for strings.. Still, great video and shows the young people the incredible power and ingenious design of the Unix OS.
"that is one process less" Piece of advice: drop this mentality. The drive to make pointless optimizations is toxic. It's a waste of your time and mental faculties. It's good to be aware of such things, but your time and efforts are better put to use on things that actually matter. I say this because I tend to fall for the allure of pointless optimizations myself.
@@majorgnu Yes, you are totally right. Don't worry, I'm not doing this, it was only kind of a joke/funny remark - like it is an additional advantage. For me, rather than having to fiddle with find, pipe, braces.. I just add * */* */*/* (that's typically enough)... its way simpler. And I mostly use fgrep since my searches often contain braces and stuff. I don't want to think what I need to escape or not, is it grep or egrep? I just type fgrep, less effort to think.At least for me, your mileage may vary, even depending on your keyboard layout. I make a lot of uses of find though, it is a great tool. But then - using many and more complex conditions etc. You always have to think if an optimization is worth the effort. For a single command, rarely ( having to type less might by a priority there), in a script or program which is run often, it may pay off over time.
This was quite serendipitous two days after watching your video I needed to delete a bunch of svg’s and I would not have thought of find if not for your video
I love your videos. So information-dense! Great point about using fundamental built-in commands on systems that you can't install unnecessary packages on.
As a linux user my self, i welcome more ways to do tasks in linux wether it is with a gui or cli, the same for browsers, i don't mind using chromium or opera, firefox for websites, TRULLY NICE WORK, CHEERS FROM TIJUANA MEXICO!
Wow, i actually think this is pretty cool that you are keep going through years! there is not so many youtubers that discuss linux and this nerd stuff, i believe in you!🥰😍
At work, we use git quite a lot, and manually making sure to run 'git pull' before I start working on a repo gets old pretty quick, so I wrote a quick find one liner that searches recursively for the .git folder, and executes 'git pull' if it finds it. This script is set as a cron job to run every morning just before I start work. Works great!
As to the point @ around 1:11, I'm really glad you made a video about find because the simpler stuff such as fd doesn't require much explanation and the deep uses of find seem really really useful!
+ vs \; I didn't know, thank you for a great little video, Veronica. I was looking to see if there was CP/M for the c64 the other day, are you keeping up with the commodore?
Great video Yes, there are newer and faster utils but at work I have much older Linux servers without access to them So knowing how to do it the "old fashioned " way is important. Plus if your scripts use them it's more portable to any system. You can always check for the presence of FD, etc and use "classic" FIND as a backup
i'm a know nothing who often struggles to find things. thank you. i'll be saving this and coming back to it for years. presuming i don't forget where i saved it.
great video! thanks! i'm a novice/intermediate linux user, & while man is helpful, sometimes a video that explains a command can be waaaay better than text on a screen. so thanks again!
Our late cat loved my C64. He was always a keyboard walker, but this was his favourite. I'm keeping up with my Commodore now, as it's safe to plug it in again.
I feel like we should mention that you shouldn't try to get to fancy with -exec; It can often lead to unwanted results. ie don't use this to rename or manipulate files on your system, but this kind of thing is fine. Also if you have not covered xargs its one of my favs.
Hilariously I’ve just started to use find for more things since being forced onto wall, terminal is all I’ve got. Now I’ve got some more trick, thanks!
I've been using 'find' since the early '80s but I'm too aware how even the earliest commands "evolve" over time so I had a look. This is a nice overview of the basic command (like others, I didn't know about the '+' delimiter, that was worth the watch by itself. One explanation that would help is how the predicates of find act as a left-to-right execution queue, meaning you can list the conditions and each will be tested and if it succeeds, find will move on to the next test. This allows really useful sets of tests where you can do things like "files owned by fred larger than 1gb whose name begins with 'p'. A really nice video, thanks! (Keeping up with the Commodore)
@@VeronicaExplains Yeah, that's true. If you're forgetfull nothing is stoping you from doing this when creating alias: && echo "full find command with switches and everything" when setting up alias, that way it will always remind you what you used and you won't forget it. In my honest opinion people should consider using alias much more. You know as well as I that used in right way ailas can be powerfull tool that gives option to use alias and full command as is. Also making alias without understanding command isn't good idea. If i make an alias for a command and i made quite a few i always do it with commands i understand, doing it with those that i don't is bad idea, after all one bad command can break entire system when it comes to linux.
@@raughboy188 for my own mileage, I try to observe common workflows that I have at a given job and develop a set of aliases and functions that become my frequently used commands toolset. Shell functions take up a space between aliases and scripts that offers greater functionality and composability that simple aliases, but generally don’t rise to the level of a full script.
Yes, Mac OS X was built off of NeXT, Steve-a-rino’s pet project during his “sabbatical” from Apple. NeXT was based on BSD, and that legacy continues. Source: I was a CS student at the time and installed OS X.1. Mind. Blown.
Nice video, and I’m happy to see people still using find. Be careful with quotes! The double quotes you used around *.txt will still allow the shell to expand the wildcard instead of passing it to find. You need to use single quotes, or put \ in front of the *. Your example passed into find a list of filenames, not the pattern *.txt
Excellent little tutorial and I look forward to the others. I've been using Linux a bit, on-and-off since 2005, and used find regularly, but consider myself a novice.
Very useful, thank you! Now I can list all files, bigger than say 100 MB in my Downloads folder, to easily spot the potential candidates for deletion, if running low on space: find Downloads/ -size +100M (with -ls at the end you get some additional details of the found files)
I find that "xargs" is more flexible and can be more powerful with options like “--max-procs (-P)” and “--max-args (n)” especially with many files and environments where a lot of control is needed
This video is a great way to familiarize people with the "find" command. You mentioned that older versions of "find" require the initial command line argument to be a path. Some newer ones will assume a default value of "." and some accept multiple paths. Additionally, the version of "find" that you use assumes "-print" as the default action. Some older versions have no default action, and display nothing if neither "-print" nor "-exec" are given. It's annoying to run "find . -name foo.txt" and see nothing when "ls foo.txt" produces output. If you do use "-exec", be sure to quote the "{}" in case some of the found files contain whitespace in their names. This is important in the presence file filesystem shares via AFS or SMB, or in any environment where some users prefer graphical file managers over the command line. I generally do not recommend using "-exec" with "find", preferring instead to use "-print" and pipe its output to "xargs" to process the found files. This makes command line quoting easier. With the "-n" option of "xargs", you have more than the "all-or-one" choices to group files, which is useful if your command shell has a length limit. With the Gnu versions of "find" and "xargs", I also prefer to use "-print0" and "-0" with these respective tools. Be aware that the "+" feature is part of the Posix specification, but it is absent from the V7 documentation. It is certainly nearly universal, but it's possible (though unlikely) that someone could find a version of "find" that is based on that ancient implementation, and have to come up with a workaround.
I feel I may be going back to the command line, thanks to this sort of thing. Also, at 1:30 I liked the undertaking to treat comments with all the patience of a substitute 8th grad maths teacher. That should be an ANSI standard.
Sorry, Vanessa i will have to disagree with you. I am not going to leave any disparagin comment. This was a great tutorial! Thank you. PS And yes learning the basics is not only important it always becomes super-useful when more complex stuff is encountered later on. Great job!
Thanks! A very nice summary of an essential command. I'm hoping that in a follow up you can find a way to cover options like -mmin and -mtime as I find those very useful when looking for recent changes. Given that like many others I didn't know about the + terminator for -exec I wonder if I'm missing some magic in date and time handling too? Also, are you keeping up with the Commodore? He's pretty quick for his age, but doesn't get to sea very often these days... ☺
Are you keeping up with the Commodore? (Cause the Commodore is keeping up with you) Actual question: What is the model of the keyboard with the awesome green keys?
I love this series. I've been using find on various *nixes for years, and still I learned something new today (and yes, I am keeping up with the commodore)
"Are you keeping up with the Commodore, 'cause Commodore is keeping up with you." I used to have a Jiffydos'd C128 with two Jiffydos'd drives...which I got used for $35 back in the 90's.....with monitor. A flood ate it. Personally, I've used locate more than find, though because it uses a database it can't help you if a file has been created between times the database got updated.
Some of you commenters are pointing out, accurately, that `grep` can recursively search files on its own, without `find`. Of course it can! But remember, grepping was just the example I was using to illustrate `-exec`. Your options between `-exec` and `{} +` are practically limitless.
Also, to those of you about to voice your displeasure with "needing the terminal to find lost files", your assignment is this word problem: "Susie has a VPS running a web server, and her server daemon has crashed due to a malformed configuration file. How can Susie identify and resolve the problem using only GUI tools and no terminal commands?"
I'm a retired UNIX/Linux System Administrator (30+ years) and I find your content refreshing and more to the point very useful! Yeah there are newer and perhaps simpler commands, but knowing the basics is still very important. People would ask me why learn vi when there is nano for example. Because from AIX to (name your Linux distro) etc, you'll always have vi :) Thanks again for your hard work and keep keep doing what you're doing!
@@occamraiser Not quite sure how to handle this, but are you aware of the fact vim has more features than nano does? Of course, if you haven't taken the time to learn vim then you won't be aware of that fact and if the pitiful nano is all you need then it's fine. But it is shite for handling text files of any non-trivial degree of length or complexity.
Ha, I learned vi on AIX 3.2 in '97
mc (Midnight Commander) has been around for 30 years. Why people are still using find, vi, nano and so on? I understand that there are some cases when there's no other choice (for example, to run certain command with all the found files), but they are very rare.
@saszab mc is great for interactive use but extremely unhelpful for shell programming.
@@DavidSchmitt Sure, but these are vary rare cases. Vast majority of the Linux users never write scripts.
In my 30 years as a sysadmin, I've never heard of the +. I've always used the \; when using -exec. Thanks.
37 years for me. I can't wait to soup up my automation scripts with + lol
Only 28 years here, and I also just learned about + from Veronica. ✌️
Only 25 years here, and I always used \; too. I'll be trying the + now. Thanks, Veronica!
hah, wait until you hear about -execdir
I decided at one point to never skip an intro to a subject for reasons like this. Sometimes you just learn something new and that is awesome!
I like the part where veronica says "its explaining time" and explains all over the place
Keeping up with the Commodore would be a reality show I would actually watch
How is the C-64 running these days?
Holy Crap! 30+ years in this business and I *just* learned about '+' as an argument to find.
How much of my life have I wasted to \; ?!
Thanks Veronica! You're frickin' awesome!
Same here, I always tended to use -print0 and pipe it to xargs -0. Thanks Veronica!
This was a real "+" for a topic. I use "find" nearly every day and did not know it has alternate endings \; Thanks.
It's a good day when there's a new video from Veronica!
I prefer `find | xargs grep` because it executes grep one time across all the found files instead of executing a separate grep for each file as find -exec would do. find | xargs grep is often an order of magnitude faster when grepping a lot of files.
EDIT: OK I wrote the above before I finished watching the video! And I see the the '+' form of exec does effectively the same thing. Wow I learned something new after using find daily for about 25 years. Thanks!
The + in my command executes once though.
@@VeronicaExplains I also learned this trick for the first time after using xargs for years. I gotta RTFM a bit more. 😁
I want to mention GNU `parallel`, which is similar to `xargs` but distributes the load across all logical cores. The only bad thing is that it requires a Perl interpreter (and many other Perl dependencies)
the xarg approach is an antipattern: it's broken with filenames containing quotes or newlines. The cure is to use GNU's versions with the -print0 predicate to find, and the -0 (or --null) option to xarg. But this is not portable, and is very awkward. -exec (or even -execdir) with + is the correct approach
I believe neither ‘+’ nor xargs necessarily put all the files as arguments to the command but parcel them up with respect to MAXARGS.
Thank you! Because honestly, even as a somewhat experienced Linux user, learning these types of tools is hard, because you only use it when you needed by looking at the long documentation, then you never touch it again so you forget. Then when you needed it once more, it's the same tedious process. A fun video like this is perfect to master a tool like this!
Started using Unix on a VAX 11/780 in the '80s before you were born!! But you're never too old to learn something new! Been using "\;" since then, and only just now learned about "+"! Thank you.
Your no nonsense explanations are great!
As someone who was "cool" in the mid-nineties, I appreciate the spacehog based puns.
I figured there was only a few who would get it.
The find command can be insanely powerful. I just learned the (+) versus the (;). Thank you for that. I had always used ; and didn't know about the +
Been a Linux user for 20+ years. Love your videos and how you extend your knowledge to newer users. Keep it up.
SHE'S A LIGHT IN THE LINUX COMUNITY !
LIKE THE GUY FROM "THE LINUX EXPERIMENT".
I've been a professional Linux sysadmin since the 90s and use the find command all the damn time. This intro was perfect, and it taught me something I didn't know - ending the command with a plus instead of a semicolon. That's super useful in many contexts - thanks for that!
saw the video couple of days ago, ended up needing this today.
You saved me a loooooot of time and troubles. you're awesome
I've been in "THE INDUSTRY" for about 8 years and I notice that:
- I still desperately need these easy basic tutorials about the most fundamental commands
- I "FIND" (wink, wink) it very calming when they're explained to me like a patient 8th grade substitute teacher would
Keep them coming!
Linux has been my development platform for work for nearly a decade, but I still watch these videos because of how fun they are. And speaking of keeping up with the Commodore, I haven't written a BASIC program in years, I realised I miss it.
Ah, but would you admit that on a CV? Right after knowing how to configure sendmail, without the help of m4?
Been using find for 25 years and still learned something new (+). Thanks!
Seriously - you're doing "god's" work. All software engineers should know the Unix shell. Linux runs the internet. I can't tell you how many professional programmers I know who cannot use BASH. It baffles me. Keep doing what you do!
find . -name "keepingupwithyou" -exec echo "Are You Keeping Up With the Commodore?" {} +
Are you keeping up with the Commodore?
Love your channel ! Very informative and entertaining !
Thank you! I have it on good authority that the Commodore is keeping up with us.
Useful and to the point. No annoying sponsorship. 👍
Never knew Gilda Radner was so into Linux. And still alive for that matter.
Using “find” with -exec is so powerful! I’ve been using it since I first discovered it in a Unix manual in 1985. Whew!
👍 for the “+” tip.
If you need absolute paths use "`pwd`" instead of .
And if you want one line per result use “find” a second time instead of “echo”
find "`pwd`" -type f -exec find {} +
Thank you, Veronica! I’m finally taking my first steps into Linux and you’re helping me ‘find’ things along the way!
Thank you for doing these Lil' Linux Lesson and concentrating on the commands that builtin rather than the newer that are not always in the repo's.
I love these videos -- if I ever have any kind of "virtual assistant" on a Linux machine, I want the voice to be Veronica Explains in 8th grade math teacher mode.
Great video, looking forward to the grep episode as well. Are you keeping up with the Commodore?
I was wondering the same thing!
'cause the Commodore is keeping up with you! Loved how simple this was, and especially the explanation of the exec parameter termination and curly braces. I've seen so many "here's how you use find to ..." tutorials and never understood what was going on with those.
I really like the editing of this video!
I need to try out a few examples tomorrow on my system, it's been awhile since I used this sequence of commands. I always used to use find then xargs then grep. Great timely video!
thanks for the different between the + and \; !
I know I had read that at one point, but forgot the difference a long while ago.
This is what I need to start my weekend, a quick explanation of how to use a command tool older than me....
And I'm 40 years old.
Your teaching skills are GOD tier. Thanks for all your hard work!
With 30+ years Unix experience I have to admit I never heard of + too. While quick, keep in mind there are limits for the size of a command line in many systems. Also, if you want to use the return value of -exec, + might not be handy. In situation like the one in in the video, I often use "grep * */* */*/* ... " as there are typically not more than 4 or 5 levels of directories. This does not need find, only the shell, that is one process less. If I get an error like "*/*/*/*/* not found" I know I added enough levels. I use this *ALL* the time. Also, I use fgrep when just looking for strings..
Still, great video and shows the young people the incredible power and ingenious design of the Unix OS.
"that is one process less"
Piece of advice: drop this mentality.
The drive to make pointless optimizations is toxic. It's a waste of your time and mental faculties.
It's good to be aware of such things, but your time and efforts are better put to use on things that actually matter.
I say this because I tend to fall for the allure of pointless optimizations myself.
@@majorgnu Yes, you are totally right. Don't worry, I'm not doing this, it was only kind of a joke/funny remark - like it is an additional advantage.
For me, rather than having to fiddle with find, pipe, braces.. I just add * */* */*/* (that's typically enough)... its way simpler. And I mostly use fgrep since my searches often contain braces and stuff. I don't want to think what I need to escape or not, is it grep or egrep? I just type fgrep, less effort to think.At least for me, your mileage may vary, even depending on your keyboard layout.
I make a lot of uses of find though, it is a great tool. But then - using many and more complex conditions etc.
You always have to think if an optimization is worth the effort. For a single command, rarely ( having to type less might by a priority there), in a script or program which is run often, it may pay off over time.
| column is the coolest thing i learned today.
It's called pipe.
@@saszab | this is pipe, that i know . i didn't know you could column like that.
This was quite serendipitous two days after watching your video I needed to delete a bunch of svg’s and I would not have thought of find if not for your video
I love your videos. So information-dense! Great point about using fundamental built-in commands on systems that you can't install unnecessary packages on.
As a linux user my self, i welcome more ways to do tasks in linux wether it is with a gui or cli, the same for browsers, i don't mind using chromium or opera, firefox for websites, TRULLY NICE WORK, CHEERS FROM TIJUANA MEXICO!
Wow, i actually think this is pretty cool that you are keep going through years! there is not so many youtubers that discuss linux and this nerd stuff, i believe in you!🥰😍
At work, we use git quite a lot, and manually making sure to run 'git pull' before I start working on a repo gets old pretty quick, so I wrote a quick find one liner that searches recursively for the .git folder, and executes 'git pull' if it finds it. This script is set as a cron job to run every morning just before I start work. Works great!
As to the point @ around 1:11, I'm really glad you made a video about find because the simpler stuff such as fd doesn't require much explanation and the deep uses of find seem really really useful!
As of this moment, fd is unlikely to be in your baseline distro, container, or enterprise approved tools list. Find will be though!
+ vs \; I didn't know, thank you for a great little video, Veronica. I was looking to see if there was CP/M for the c64 the other day, are you keeping up with the commodore?
Great video Yes, there are newer and faster utils but at work I have much older Linux servers without access to them So knowing how to do it the "old fashioned " way is important. Plus if your scripts use them it's more portable to any system. You can always check for the presence of FD, etc and use "classic" FIND as a backup
i'm a know nothing who often struggles to find things. thank you. i'll be saving this and coming back to it for years. presuming i don't forget where i saved it.
great video! thanks! i'm a novice/intermediate linux user, & while man is helpful, sometimes a video that explains a command can be waaaay better than text on a screen. so thanks again!
oh, and, are you keeping up with the commodore?
"Have you played Atari today!"
(No commodore because I'm a rebel. "
ZX Spectrum rulez!
Our late cat loved my C64. He was always a keyboard walker, but this was his favourite. I'm keeping up with my Commodore now, as it's safe to plug it in again.
8:04 I prefer the ZX Spectrum.
I feel like we should mention that you shouldn't try to get to fancy with -exec; It can often lead to unwanted results. ie don't use this to rename or manipulate files on your system, but this kind of thing is fine. Also if you have not covered xargs its one of my favs.
Whenever I do potentially dangerous actions with scripting I always do a "dry run" with echo before the actual command name.
Hard to believe it has been 30 years since the demise of C=. My A-3000 still rocks, and my C= 128 is still great.
100%. You can get by just fine without using locate but you have to use find at least sometimes!
Hilariously I’ve just started to use find for more things since being forced onto wall, terminal is all I’ve got. Now I’ve got some more trick, thanks!
I've been using 'find' since the early '80s but I'm too aware how even the earliest commands "evolve" over time so I had a look. This is a nice overview of the basic command (like others, I didn't know about the '+' delimiter, that was worth the watch by itself. One explanation that would help is how the predicates of find act as a left-to-right execution queue, meaning you can list the conditions and each will be tested and if it succeeds, find will move on to the next test. This allows really useful sets of tests where you can do things like "files owned by fred larger than 1gb whose name begins with 'p'. A really nice video, thanks! (Keeping up with the Commodore)
To simplify find as much as possible rather than memorising huge command you can also implement alias for it.
You can, but I think if you're a professional sysadmin (or hoping to become one), you'll still have to understand it without the alias.
@@VeronicaExplains Yeah, that's true. If you're forgetfull nothing is stoping you from doing this when creating alias: && echo "full find command with switches and everything" when setting up alias, that way it will always remind you what you used and you won't forget it. In my honest opinion people should consider using alias much more. You know as well as I that used in right way ailas can be powerfull tool that gives option to use alias and full command as is. Also making alias without understanding command isn't good idea. If i make an alias for a command and i made quite a few i always do it with commands i understand, doing it with those that i don't is bad idea, after all one bad command can break entire system when it comes to linux.
@@raughboy188 for my own mileage, I try to observe common workflows that I have at a given job and develop a set of aliases and functions that become my frequently used commands toolset. Shell functions take up a space between aliases and scripts that offers greater functionality and composability that simple aliases, but generally don’t rise to the level of a full script.
The moment I learnt how to use find, I felt like I had unlocked a superpower.
Yes, Mac OS X was built off of NeXT, Steve-a-rino’s pet project during his “sabbatical” from Apple. NeXT was based on BSD, and that legacy continues.
Source: I was a CS student at the time and installed OS X.1.
Mind.
Blown.
Too bad you couldn't try Apple A/UX. Best environment before OS X, and in some ways it was better although it's unusable after Y2K.
Nice video, and I’m happy to see people still using find.
Be careful with quotes! The double quotes you used around *.txt will still allow the shell to expand the wildcard instead of passing it to find. You need to use single quotes, or put \ in front of the *.
Your example passed into find a list of filenames, not the pattern *.txt
Excellent little tutorial and I look forward to the others. I've been using Linux a bit, on-and-off since 2005, and used find regularly, but consider myself a novice.
Are you keeping up with the Commodore?
I lol'd at "all the patience of a substitute 8th grade math teacher."
Veronica, your are the miracle!
Very useful, thank you!
Now I can list all files, bigger than say 100 MB in my Downloads folder, to easily spot the potential candidates for deletion, if running low on space:
find Downloads/ -size +100M
(with -ls at the end you get some additional details of the found files)
Recent Linux convert that"s keeping up with the commodore. Finding these videos super helpful for making my transition easier
I never understood the find command... Until now! Thanks, Veronica!
love it, keep 'em coming
This is a good series.
Also, are you keeping up with the Commodore?
I've been using find like this for nearly 30 years. I remember when -print was required to see the filename. I didn't know it was mystery.
I still have my C64, 1541 and a lot of floppies at my brother's place. Blue Max, Castles of Dr Creep etc, lots of memories.
I find that "xargs" is more flexible and can be more powerful with options like “--max-procs (-P)” and “--max-args (n)” especially with many files and environments where a lot of control is needed
Thanks for another entertaining video!
This is the kind of content I need being I have no idea how to do many basic Linux stuff
I am keeping up with the Commodore after you helped me find it!
Love these little tidbits. Easier to commit then to memory when it isn't one of 10+ all presented at once.
Looking forward to grep
This video is a great way to familiarize people with the "find" command. You mentioned that older versions of "find" require the initial command line argument to be a path. Some newer ones will assume a default value of "." and some accept multiple paths.
Additionally, the version of "find" that you use assumes "-print" as the default action. Some older versions have no default action, and display nothing if neither "-print" nor "-exec" are given. It's annoying to run "find . -name foo.txt" and see nothing when "ls foo.txt" produces output. If you do use "-exec", be sure to quote the "{}" in case some of the found files contain whitespace in their names. This is important in the presence file filesystem shares via AFS or SMB, or in any environment where some users prefer graphical file managers over the command line.
I generally do not recommend using "-exec" with "find", preferring instead to use "-print" and pipe its output to "xargs" to process the found files. This makes command line quoting easier. With the "-n" option of "xargs", you have more than the "all-or-one" choices to group files, which is useful if your command shell has a length limit. With the Gnu versions of "find" and "xargs", I also prefer to use "-print0" and "-0" with these respective tools.
Be aware that the "+" feature is part of the Posix specification, but it is absent from the V7 documentation. It is certainly nearly universal, but it's possible (though unlikely) that someone could find a version of "find" that is based on that ancient implementation, and have to come up with a workaround.
Great explanation in 8 minutes especially exec +
Thanks! That's my goal with these, trying to keep them under 10 minutes and still thorough.
This video format is amazing!
Hi Veronica. I'm amazed by your passion for computers! I really appreciate your videos. Cheers!
Veronica, you are my spirit animal!
So to follow instructions, "are you keeping up with the Commodore." :) Though my historical computer studies tend to focus on stuff a bit older.
I feel I may be going back to the command line, thanks to this sort of thing. Also, at 1:30 I liked the undertaking to treat comments with all the patience of a substitute 8th grad maths teacher. That should be an ANSI standard.
Sorry, Vanessa i will have to disagree with you. I am not going to leave any disparagin comment. This was a great tutorial! Thank you.
PS And yes learning the basics is not only important it always becomes super-useful when more complex stuff is encountered later on.
Great job!
I never touched a Commodore as a kid, but an MSX. But sometimes I feel more nostalgic with an 286 AT.
Super awesome love the jams! Great info! Are you keeping up with the commodore?
Thanks! A very nice summary of an essential command.
I'm hoping that in a follow up you can find a way to cover options like -mmin and -mtime as I find those very useful when looking for recent changes. Given that like many others I didn't know about the + terminator for -exec I wonder if I'm missing some magic in date and time handling too?
Also, are you keeping up with the Commodore? He's pretty quick for his age, but doesn't get to sea very often these days... ☺
The find command is one of the commands that I always have to look up the instructions for when I need it :)
Are you keeping up with the Commodore? (Cause the Commodore is keeping up with you) Actual question: What is the model of the keyboard with the awesome green keys?
I love this series. I've been using find on various *nixes for years, and still I learned something new today (and yes, I am keeping up with the commodore)
Thanks for making this useful video, I didn't know the find command existed until now
Awesome video Veronica, I loved this type of video with a specific linux topic!
Thank you for the support! More videos like this are on the way!
"Are you keeping up with the Commodore, 'cause Commodore is keeping up with you." I used to have a Jiffydos'd C128 with two Jiffydos'd drives...which I got used for $35 back in the 90's.....with monitor. A flood ate it. Personally, I've used locate more than find, though because it uses a database it can't help you if a file has been created between times the database got updated.
Just doing the thing to say do more of these things!! Many thanks Veronica 🙂. Are you keeping up with the Commodore?
Are you keeping up with the Commodore? I never did. I started on the ZX Spectrum!😁
Me too. Moreover, I had to solder and assemble it by myself. Because in the USSR if you wanted to have a computer you had to make it by yourself :-)
》I have no complaints at all.
Another interesting and informative video. Are you keeping up with the Commodore?
I use to open intellij each time to search over project files. I learned to use "find" today.
I love your damn videos. I can't wait to see where this channel is at this time, next year. No pressure, though!