Asking because I'm at a bit of a crossroads - I have a good handle on about 5% of the command line knowledge which gets me through 80% of the stuff I need to do. I'm wondering if learning to use more commands is worth the effort when I can already get the task done without using the command line?
E.g. there was a time in my life when I didn't get what `xargs` even did, I literally couldn't grok it. Now, I can't imagine life without `-0`!
The composability of UNIX commands is just so amazing. Every command builds on every other command. I haven't seen that with any other tools or program.
e.g.:
find . -type f -print | xargs wc -l
find . -type f -print0 | xargs -0 wc -l
If you're doing processing on other inputs which may include whitespace, you'll be able to handle those using xargs without worrying about additional delimiting.
And for those not aware, '-print0 / -0' arguments to find(1) and xargs(1) respectively tells the first to output ASCII NUL delimited arguments, and for the latter to expect the same. As ASCII NUL should not normally occur within any argument, it's the ultimate delimiter.
I've used xargs and/or bash loops to do some fairly heavy-duty web scraping given an input list of arguments. Using xargs allows multiple simultaneous parallel queries such that any one request stalling out doesn't hold up all process.
"wc -l" gives a line count for a file. That's ... not especially advanced, but is a trivial example of an xargs command which you should be able to try without causing any problems on your own system.
If you get a sense of things you can do with (|, & , >) and a dozen or so commands like
sort | uniq | cut | paste | join | head | tail | sed | awk | wc | tr | fmt | col | nl | pr | find | grep | tar | export
The value you get in return is intense for the effort invested.
Plus, in the 10 years i've been maintaining code, bash scripts are the minority that still work as they used to with almost no change needed.
That single handedly is worth my money.
A lot of cut invocations I see are on CSV files, and are all bugs out of the gate.
(But use JSON, if you can. It's a step up, and easier to work with, particularly with jq.)
I've seen hours wasted writing jankey one off c++ utils, for lack of knowing that grep/awk exist.
Being able to tail a dev log and filter it for errors is also a part of seasoned developer competence too, I'd say.
For this and other reasons, I will often write programs as command-line using standard I/O for most data. For example, a music playing program which reads the music file from stdin and writes the audio data to stdout which is taken by aplay to play the audio on the speaker. (In this way, you can also add other thing in between such as special effects, if desired.)
(It is also useful for other programs (interactive or GUI or whatever) to have the opportunity to open pipes with other user-specified programs; Meirloom-mailx is one interactive command-line program does it (I often use that feature to display pictures attached to messages), and Free Hero Mesh (which has GUI) also exclusively uses such pipes to import/export levels and pictures and move lists.)
The rest of the book offers a somewhat longer-form answer.
Another reference I'd strongly recommend is the O'Reilly UNIX Power Tools book, which though it turns 30 as of the new year remains one of the best "what are some really useful recipes" books about and for Unix / Linux.
That is freely available here (3rd edition):
<https://mathcs.duq.edu/~juola/UnixBooksPDF/unixpowertools.pd...> (PDF)
It lacks many things provided by a POSIX shell (nearly all of which are present in the later Korn shell).
There are many entire operating systems that survived only a fraction of this time. I think that it will remain relevant for decades.
Command line programs compose like this, GUIs don't.
I suppose it's a super rare occurrence now, but back when I was starting on this, I would mess up my X server and was forced to fix it from the command line.