Defensive Bash programming

The article mentions so many topics, but misses almost all important ones.<p>* First of all, use proper quoting. There are so many possibilities for file names, command line arguments, etc. that every unquoted usage of a variable is essentially a security risk.<p>* Then, start your script with &quot;set -e&quot;, which stops the script whenever one of the commands fail, instead of blindly continuing and messing things up. This is the most important option for robust shell scripts.<p>* Also use &quot;set -u&quot; which makes the script stop on undefined variables. This includes $1, $2, etc., so it provides checks for missing arguments for free.<p>* In addition to &quot;set -e&quot;, also set &quot;set -o pipefail&quot;, otherwise a pipe will only break if the last command fails, while with &quot;set -o pipefail&quot; the pipe fails whenever any command of the pipe fails.<p>* After that, you may continue with spacing issues in &quot;for&quot; loops, and that you should not pipe the &quot;find&quot; output directly (instead, use either &quot;-print0&quot; + &quot;xargs -0&quot;, or use &quot;-exec&quot;), and similar stuff.<p>When you got all of this right, and only then!, you may start worrying about the (relatively) minor issues mentioned in the article.

The first rule of defensive bash programming should be: quote everything. Incredibly, the article doesn&#x27;t mention quoting at all, doesn&#x27;t even use it silently in examples.

Generally, bash is for quick and dirty things I want to automate. I&#x27;ll go to perl or python if I need anything more complex.<p>The amount of effort put into these examples is already way higher than my personal sniff test for &quot;Should I be doing this in something besides bash?&quot;

If you do have the choice, the first rule of defensive bash programming is to not program in bash. But otherwise it was a great article.

I freaking love &quot;set -x&quot; and wish every language had an equivalent. When I switch from bash to another language I miss &quot;set -x&quot; deep in my soul.

You can use the pipe | as a continuation at the end of a line. No need to use the backslash escape then. i.e. you never should need to use | \ at the end of a line.

Defining a function for is_file as [[ -f $blah ]]; seems like defining a function for var++ as increment_one() ...

And yet he pipes from ls...

Yes, of course. Use more bashisms, wait for bash to change its behaviour in those bashisms (it already happened and was not that rare) and happy debugging.

I thought that UPPER_CASE variables were a bad idea? Doesn&#x27;t the bash world generally accept that you should use uppercase only for enviornment variables, and lowercase for variables in the script&#x27;s context?

Is threesome kind of secret code embedded in the typos?

Corporate gateway seems to not like this domain:<p>This web site ( www.kfirlavi.com ) has been blocked because it has been determined by Web Reputation Filters to be a security threat to your computer or the corporate network. This web site has been associated with malware&#x2F;spyware. Reputation Score for www.kfirlavi.com: -7.1<p>Reputation scores can range from -10 (worst) through 10 (best).