You mean you don't just go read the man page for every bash command and intuitively understand it?

Sorry for the sarcasm, I just feel your pain. Learning even basic things in bash has been slow for me too. I love it. I prefer it to GUIs on most things I have figured out.

But there's so much to learn.

I spoke about bash and this exact thing here:

https://www.youtube.com/watch?v=pb3k0sGKrjQ

Plug for book that resulted:

https://leanpub.com/learnbashthehardway

UNIX Power Tools, written in 1992, once filled much of this niche. It badly needs updating and augmenting, or a novel replacement.

Or learning git from its man pages.

https://www.mercurial-scm.org/pipermail/mercurial/2015-March...

from a sibling comment: http://www.tldp.org/LDP/abs/html/ seems to be great :)

It isn't as good as: https://mywiki.wooledge.org/BashGuide (which is the one that gets recommended on #bash @ freenode). Also: https://shellcheck.net

Well, the way this person uses ImageMagick can hardly be described as "basic". In fact, he's a wizard. If you look through the bullet points at the top, he links to an impressive CV and PDFs with mathematical descriptions of how some of his scripts work.

Explains concepts: https://www.youtube.com/playlist?list=PLFAC320731F539902

If you can spare the time read these two, the first one is free.

http://linuxcommand.org/tlcl.php/

https://www.amazon.com/UNIX-Linux-System-Administration-Hand...

The best way to learn in my opinion is to find someone who knows more than you and have them be your mentor. You don't even have to ask them directly, though many people I think are glad to teach.

Identify someone at your work or school who you feel always has a nice perspective and who you trust; then seek out their opinion and advice when you have questions. You can learn a lot in a fairly short amount of time by applying this practice.

You can also find what I've heard called "silent teachers" - there's no formal or informal relationship between the two of you, but you're always watching what they say, observing the things they care about, etc.

If you're in a situation where you're not employed full-time in a technical position it becomes a little harder but you can still do it. Much of it depends on your local context.

You can scroll through /bin, /usr/bin/ and /usr/local/bin/ and find all the included basic tools and then read "man 'tool'" or google for it

This is not practically useful advice.

That's how I learned a lot of things; by literally scanning through everything it had to offer and googling what I didn't understand. I did that for linux utils, language references, most programs I use and most codebases I had to work on.

One notable example is the time I had to learn C# 4 years ago. It took an entire morning to scan through the entire language reference and then later I found out I already knew a lot more than "advanced" devs who would just look up stuff as they needed it, without knowing what actually is available in the first place.

I feel its the only sensible advice if you want to learn a lot on your own with limited time.

My experience has been that it’s most important to get started. Then you can scan and read man pages etc.

It's how I learned, back in dial-up days.

Coreutils is a good place to start.

http://www.gnu.org/software/coreutils/coreutils.html

I’m not saying you can’t learn this way. I’m saying it’s not practical for most people. Many people who would fail this way would succeed other ways. Reading man bash as primary learning material will lead to failure for 999/1000 humans.

Try 'info bash', it's a lot easier to browse. 'info' by itself gives you a menu of installed info documentation. 'C-h i' in Emacs.

That just means the man page you're using sucks.

I’ve wanted to read man bash, and believe me, I’d think I was the kind of person who would (I learned Go just reading the spec. It’s a great spec), but man bash and many other man pages have never worked for me. Maybe if I tried again now.

bash, incidentally, has a man page that sucks. I've found that most larger GNU projects have pretty horrible man pages. Probably due to feature creep in said projects - so the manuals have to be large to cover all the features.

I spent 10 years avoiding awk, because every time I typed 'man awk' I was overwhelmed by the GNU monstrosity. Then I found the man page for the plan9 implementation of awk (http://man.cat-v.org/plan_9/1/awk) and learned the language in fifteen minutes.

> I've found that most larger GNU projects have pretty horrible man pages. Probably due to feature creep in said projects - so the manuals have to be large to cover all the features.

Rather, info manuals are GNU's official (self-invented I think) documentation system. They make manpages only because of their popularity, but they direct you to the info pages for more info. When other projects have too much documentation for a manpage, they split it among several pages, like perl, openssl, zsh, git, borg, btrfs, etc. Personally, I like both, and wouldn't rank one above the other.

It's far better than Googling or guessing for them. Looking in those places provides exactly what is on your system and the man pages exactly describe what they are for.

If there is a better source, I don't know it.

Yes, it is practically useful advice, especially when you’re on a flight with no WiFi.

That’s a good use case. Believe me I’m into man pages. Every 6 months I check the Apple store to see if anyone has created a good man pages app. But as primary learning material for most people: not so sure.

That is exactly how I learned how things worked.

I never thought of that, and said to myself, "Hmmm... that is a good idea."