I kind of like that BASH allows you to make unconventional programs.
Defensive BASH programming
11–20 of 53 posts
Re: Defensive BASH programming
#12Yes, I applied some of these in my bash program.
Re: Defensive BASH programming
#13Very interesting article and I agree with most of the points. One point I strongly disagree is what is called "Code clarity" where the author replaces conditional expressions (https://www.gnu.org/software/bash/manual/html_node/Bash-Cond...) by function calls.
I agree that the function call introduces a better name. The problem is that this name is specific to the author of the script. It replaces a reusable tricky knowledge of the language by a simple knowledge of the author usages.
If we take into account the increased verbosity, increased typing, increased number of lines, there is a clear loss in using these functions.
For me, adding a comment would be far enough and far less annoying.
Re: Defensive BASH programming
#14I think the best "defensive" piece of advice you left out that everyone abuses is never pipe `find` results to `xargs.` One should always do `find ... -print0` to a read-while loop because of filenames with whitespace.
avoid read-while loop... there are problems with filenames starting/ending with spaces...
better use
find ... -print0 | xargs -0 ... [eventually with -n1]Re: Defensive BASH programming
#15All these recommendation are excellent (except omitting the necessary obsessive quoting of all variables everywhere (just in case they contain a space). I've been enjoying BATS [0] for my bash testing. [1] https://github.com/sstephenson/bats
Why BATS? Why not something *unit-like? Example: https://github.com/vlisivka/bash-modules/blob/master/main/ba... .
Re: Defensive BASH programming
#16I'm not sure if scripting can be consider programming. Excessive scripting means lack of software architecture, no to mention the least efficient way to work with the FS
Depends on how you define scripting vs programming. I'd argue that you can "program" in a shell language; bash is Turing-complete after all.
Whether doing so or not is a good idea is another question entirely..
Re: Defensive BASH programming
#17I think the best "defensive" piece of advice you left out that everyone abuses is never pipe `find` results to `xargs.` One should always do `find ... -print0` to a read-while loop because of filenames with whitespace.
Use "find ... -exec command '{}' '+'" instead of "find | xargs command".
Re: Defensive BASH programming
#18IMHO, it is much easier to parse arguments using bash_modules args module (disclosure: I am author).
Re: Defensive BASH programming
#19Slightly off-topic but maybe some people will find it useful:
I used to write my various glue-things-together scripts in bash, but this quickly becomes a nightmare as the script grows, due to bash's corner cases, syntax, portability issues etc.
Recently I wrote my massive glue-things-together script with nodejs (since I already use node for many things) and it's much more maintainable and I couldn't be more happy. Node 0.12 has execSync which was the missing piece for making node the proper shell scripting platform.
If you are interested, you may want to check shelljs [1] and my snippets for robust `exec()` and `cd()` in node.
[1] https://github.com/shelljs/shelljs [2] https://gist.github.com/jakub-g/a128174fc135eb773631
Re: Defensive BASH programming
#20The only thing in this post that can be accurately called defensive is the use of "local" and "readonly". The rest is all just style preferences, which are rather subjective, and none of which are very appealing to me.
Three real defensive bash programming tips are:
- Quote all uses of variables
- set -o nounset
- set -o errexit
And many others can be found in and around http://mywiki.wooledge.org/BashFAQ