[majewsky]

In addition to what others said, I can recommend just reading through the manpage once (probably in multiple sittings). Even if you don't remember the exact syntax, you will have an idea what bash can do, and know enough of the jargon to find it again in the manpage when you need it. For example, when I need to replace a substring, I used to do

  FOO="Hello World"
  ...
  BAR="$(echo "$FOO" | sed "s/World/Hacker News/")"

until I remembered that bash can do string replacement by itself. A quick search for "pattern" and "substitute" in the manpage turned up the right syntax,

  BAR="${FOO/World/Hacker News}"

[dozzie]

I would also recommend to read Single Unix Specification on shell syntax, and then avoid bashisms whenever possible. Bash had a history of subtly changing its behaviour in these, which leads to scripts getting suddenly broken without any modification on system update.

[zanchey]

Could you give some examples? http://wiki.bash-hackers.org/scripting/bashchanges and http://wiki.bash-hackers.org/scripting/obsolete aren't particularly enlightening.

[dozzie]

What I was hit with were subtle changes to how [[ ]] worked, along the lines of implicit anchoring in pattern in previous version not taking place in succeeding version. It took quite a while to debug what became a logic error.

After that I started avoiding bashisms in my scripts, especially that they usually provide very little benefit at the cost of gambling against breaking silently on a barely related update.

Nowadays it's also worth noting that #!/bin/sh often (Debian derivatives) points to something that is not Bash, and people writing in shell/Bash usually don't understand the difference.

[dredmorbius]

I'd recommend reading the manpage far more than once.

It runs about 70-80 pages, so counts as a small book.

Hrm. Make that 107 pages:

    man bash | pr | grep 'Page [0-9][0-9]*' | tail -1

46,000 words.