First, if your bash script grows beyond about ten lines, it's time to consider rewriting it in a cleaner language. Python's a common one. I used to use Haskell for that kind of scripting as well, which was astonishingly good at it.
Here's my study suggestion:
0. Learn to use variable interpolation and backticks.
1. if blocks and the [ built-in function. Go read about the grammar and look at the flags that [ takes. Memorize the most common couple (file exists, is a directory), and know how to look up the others when needed. Find examples of variable interpolation tricks needed to make this function.
2. for and while blocks. Learn the grammer. for is mostly useful with `seq ...` or a file glob.
3. Learn some of the options to make bash fail early and loudly like pipefail.
4. Most of the power of bash is in the programs you call, and they aren't always the same ones you use interactively. Other folks have mentioned some of these. find, xargs, wait...
I agree that writing long, monolithic scripts isn't optimal, but there's no reason you can't break a large script into multiple smaller scripts. And there are certain tasks where <programming language of choice> won't offer any advantage over using a regular ol' shell script. If one really needs/wants to get into Bash, I'd recommend learning it well enough to make educated decisions about when Bash starts becoming a pain, and the benefits of <programming language of choice> start to kick in. In some cases, a <programming language of choice> will be more of a hinderance than a help, especially in areas where the the functionality you want cannot be found in the standard library.
> if your bash script grows beyond about ten lines, it's time to consider rewriting it in a cleaner language
Just because you don't feel comfortable writing long scripts doesn't mean you should discourage others.
There are many many justifications for sticking to shell, for example if you need to write a portable installer that works across every UNIX variation.
> Just because you don't feel comfortable writing long scripts doesn't mean you should discourage others.
And deprive them of the hard learned lessons from decades of experience?
> There are many many justifications for sticking to shell, for example if you need to write a portable installer that works across every UNIX variation.
Do you mean every Linux variation? Because trying to write shell portable from old HP-UX to Darwin is an exercise in insanity.
Here's my study suggestion:
0. Learn to use variable interpolation and backticks.
1. if blocks and the [ built-in function. Go read about the grammar and look at the flags that [ takes. Memorize the most common couple (file exists, is a directory), and know how to look up the others when needed. Find examples of variable interpolation tricks needed to make this function.
2. for and while blocks. Learn the grammer. for is mostly useful with `seq ...` or a file glob.
3. Learn some of the options to make bash fail early and loudly like pipefail.
4. Most of the power of bash is in the programs you call, and they aren't always the same ones you use interactively. Other folks have mentioned some of these. find, xargs, wait...