2 ms·
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"
by chubot 13y ago
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.
- onli 13y ago> 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?
- claudius 13y ago$ 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.
- elwin 13y ago> 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.)
- claudius 13y agoTIL. Thank you very much! :)