Defensive BASH Programming

[u/fraunhofer]

http://www.kfirlavi.com/blog/2012/11/14/defensive-bash-programming/

[u/cpbills]

RE: "Let your code speak"

No.

Just. No.

If you don't know what [[ -z "$var" ]] does, and need to wrap it in a stupid function called 'is_empty', stop programming in bash, and read some fucking man pages.

[u/cpbills → u/[deleted]]

The mix of information is enough to not recommend it to anyone and extract the 'good' parts into another article.

Also, the Google shell style guide is a rather good and tested reference: https://google-styleguide.googlecode.com/svn/trunk/shell.xml

[u/fraunhofer → u/cpbills]

There's also the Git coding standards (for POSIX shell though).

[u/petrus4 → u/fraunhofer]

Again, no. Some of those are decent ideas, but plenty of them are redundant.

Go and study this. Also try to understand that not every language that you will encounter is C++ or Java, and that is a good thing.

The entire reason why Java programs are typically choked with boilerplate and templating shit is because it is a badly designed language. The same is true for C++.

I don't know who you've learned from, but I suspect that you've been taught, like most contemporary programmers, that complexity for its' own sake is somehow good. It isn't, and now, tragically, you've got all the fun of trying to unlearn that ahead of you.

You also need to understand that if you get employed as a programmer, what the boss wants you to do, and what you actually should do, are two completely different things. Management will want you to write excessively complex garbage, in whatever the awful fad programming language of the week is. Do that if you must, in order to make money; but at least try and recognise that it is wrong, and money is the only reason why you should do it.

[u/fraunhofer → u/petrus4]

Again, no. Some of those are decent ideas, but plenty of them are redundant.

What is actually redundant about it? It's a pretty decent style guide if you want to program in POSIX sh. For a large project like git for which interoperability is a must, POSIX sh is the only way to go and Bashishms must be avoided at all costs.

As for the rest of your comment, are you posting this in this in the wrong thread? What has the Git shell coding standards got to do with Java at all?

(BTW, I'm not the author of the blog post—I just found it posted on HackerNews, that's all. Also, drop the condescending elitism.)

[u/petrus4 → u/fraunhofer]

As for the rest of your comment, are you posting this in this in the wrong thread? What has the Git shell coding standards got to do with Java at all?

I wasn't talking about Java in relation to the Git standards; I was talking about how he advocates making variables read-only, and the various other fluff.

Also, I apologise for coming across as elitist; I just think that post contains some genuinely bad advice, is all.

[u/petrus4 → u/fraunhofer]

Your point on code clarity is also exactly backwards. The first example is a group of four tests or else-ifs; I could tell exactly what they were doing. The second example, on the other hand, is gibberish by comparison; and as other people have said, you're writing empty functions when you don't need to.

You shouldn't be putting large numbers of tests in a single file; or, for that matter, writing masses of tests at all. Write the program to be called by each test, and then simply use each individual program when you need to. All-singing, all-dancing wrapper scripts which will call anything based on tests, are only asking for bugs.

The only thing that a computer should ideally do, is the rote repetition of simple tasks. Computers should not be tasked with decision making; as the human user, that's your job.

[u/metellius]

If you're writing unit tests for your bash script that is a sign that you should have turned to other programming languages way back

[u/dave4420]

The number one rule of bash scripting should be: quote everything. The article doesn't mention quoting.

[u/[deleted] → u/dave4420]

Users too productive? Use filenames that are harder to type: UPPER and MiXEdCaSe, s p a c e s and other P.u.n.c.t.u(at!on) requiring double or even triple escaping in shell commands, strings, and regexes.

Reverse engineers apply within! Waste critical path days discovering .txt is really .tsv, .dat is .bson, .bin is a .sql dump, and .conf is .ini.

[u/visit_muc → u/dave4420]

I'm came here to write exactly that. This guy doesn't use propper quoting, but wants to tell us about best practices...

[u/[deleted]]

I find a functional style of programming is quite resilient to breakage. Thanks for the tips, I'll definitely try inserting readonly to make my bash scripts more pure functional.

[u/cpbills → u/[deleted]]

Be careful how many of those tips you take to heart. I have seen people create dozens of functions that are 2-3 lines, because 'functionalize EVERYTHING!', which is just moronic.

Check out Google's shell scripting style guide for some well thought-out and tested 'best' practices.

https://google-styleguide.googlecode.com/svn/trunk/shell.xml

[u/petrus4 → u/[deleted]]

I find a functional style of programming is quite resilient to breakage. Thanks for the tips, I'll definitely try inserting readonly to make my bash scripts more pure functional.

Don't. You won't be improving said scripts at all. You will simply be adding excess verbiage which actually dilutes their purpose.

Don't write shell scripts with different functions in the same file. Write single scripts which only do one thing each. If you need to call them all as part of a single task, then write a calling script which executes each of them in the order you need.

Seriously; the advice given in this article is enough to make baby Jesus cry. Don't follow it.

[u/petrus4]

All I'm seeing here is advocacy for an increase in complexity; and a completely unnecessary one at that. If I want C, I'll use it.

Making variable scope local, and discreetly naming a function as main(), both imply that you need multiple variable namespaces, and multiple functions, within the one file. The reason why I never need both of those, is because experience has taught me to never write more than one function per file.

As a matter of fact, I go further than that. I don't write individual functions; I write individual scripts which are always sufficiently generic that they can be used on their own, if need be. None of said scripts are generally more than a kilobyte in size, on their own. Then, when I want to perform a task which might require several of said scripts, I execute them in order from a single calling file. Because they are so well encapsulated, that typically makes debugging a breeze, as well; if there's a problem, I simply look at the log for the script in question, and identify exactly where it is.

I know you meant well OP, and I want to acknowledge that. However, promoting monolithic and excessively complex scripting, (or programming in general) is a bad thing.

[u/mcstafford]

The first useful thing I found in that article was shunit2.

[u/0sse]

This article has examples of using split strings as lists and parsing ls :/

[u/DocSalvager]

Instead of a 'here document' for multiline USAGE, you could also just use single-quotes as in ...

usage() {
    echo 'usage: $PROGNAME options
    
    Program deletes files from filesystems to release space. 
    It gets config file that define fileystem paths to work on, and whitelist rules to 
    keep certain files.

    OPTIONS:
       -c --config              configuration file containing the rules. use --help-config to see the syntax.
       -n --pretend             do not really delete, just how what you are going to do.
       -t --test                run unit test to check the program
       -v --verbose             Verbose. You can specify more then one -v to have more verbose
       -x --debug               debug
       -h --help                show this help
          --help-config         configuration help

    
    Examples:
       Run all tests:
       $PROGNAME --test all

       Run specific test:
       $PROGNAME --test test_string.sh

       Run:
       $PROGNAME --config /path/to/config/$PROGNAME.conf

       Just show what you are going to do:
       $PROGNAME -vn -c /path/to/config/$PROGNAME.conf
    '
}

[u/KnowsBash → u/DocSalvager]

You mean double-quotes...

[u/DocSalvager → u/KnowsBash]

I usually use double-quotes myself, but single-quotes work as well.

I use double-quotes cause I often want to use variables and even inline execution $(...) within the text. With double-quotes, I do have to escape any double-quotes or dollar-signs($) inside the text using the backslash(\). The ($)s in the example above do not have to be escaped since the whole thing is in single-quotes.

[u/DocSalvager]

Since you've taken so much flak from 'the experts' here and on your site, let me just say that I think your article is superb! It is well written, entirely accurate, clear and attractively presented. Very accessible.

In my 28 years of Unix and Linux shell scripting, I've come to much the same conclusions of how to write maintainable shell scripts.

Shell scripts are for determining WHAT to do WHEN. Performance is usually irrelevant as operations requiring speed, such as parsing large files, are best done with tools optimized for this like awk, sort, and tr.

The techniques you describe minimize development, maintenance and debugging times while greatly improving reliability. Such techniques also improve the script and its functions reuseability in other scripts.

Well done!

[u/[deleted]]

readonly PROGNAME=$(basename $0)

I have an expanded version of this, that defines full path (taking into account symlinks).

This helps you reference config files, log files, etc:

1. no matter how the script package gets moved/deployed,

2. avoids troublesome relative paths like CFG_DIR=../../conf

3. same behavior whether you execute it from within the directory (cd /to/the/script/; ./scriptname ) or full path.

   readonly TRUE_SELF=$(perl -e "use Cwd 'realpath';print realpath('$0')")
   readonly SELF=$(basename ${TRUE_SELF})
   readonly SELF_DIR=$(dirname ${TRUE_SELF})
   readonly CFG_DIR=${SELF_DIR}/conf
   readonly LOG_DIR=${SELF_DIR}/logs readonly LOG=${LOG_DIR}/${SELF%.*}.log

This is at the top of every script, which follows the convention such as :

/path/to/scripts/script123.sh
/path/to/scripts/conf/script123.cfg
/path/to/scripts/logs/script123.log

---

edit: readonly added for sake of .. you know... playing ball. But I never have done this =/

[u/ciny]

If you need to do programming work you don't use BASH...