Here are the quoting rules I use:

  - Avoid paths with spaces :)
  - If you have to handle paths with spaces, use double quotes everywhere,
    e.g. "$pidfile".   
  - Always use "$@".  I've never found a reason to use $@ or $* unquoted.

I also write unit tests (in shell) if there is something unusual I know I have to handle.

That's it. I don't think it's hard at all, although you will certainly see scripts in the wild where the author was confused about quoting, and quoting hacks pile upon hacks. If you use a consistent style, it's very smiple.

There is a learning curve like there is with any language, but it's totally worth it. Shell is an extremely powerful language, and saves you MANY lines of Python code.

I would say Python is definitely the easiest language to learn, but bash is not harder than say JavaScript.

> If you have to handle paths with spaces, use double quotes everywhere, e.g. "$pidfile".

I'd like to add: Always use double quotes around paths. Or is there something I'm missing here?

  $ ls -l "*"
  ls: cannot access *: No such file or directory

Of course, you might want that exact behaviour, but sometimes you want e.g. all .table files in a path with a space. I believe

  $ ls -l "path with/lots of spaces/"*

is the correct solution, but it seems silly. I'm not entirely sure why variable expansion works inside double quotes but wildcard expansion doesn’t.

> I'm not entirely sure why variable expansion works inside double quotes but wildcard expansion doesn’t.

That's because a double-quoted expression is supposed to evaluate to a single word. Wildcard expansion can result in multiple words, but parameter expansion doesn't.

(Except for things like "$@". With bash, the rules always have exceptions.)

TIL. Thank you very much! :)

A basic technique in bash is "UMQ": Use More Quotes