Better bash in 15 minutes

If you&#x27;re using:<p><pre><code> set -o errexit # or set -e if you prefer </code></pre> Then you probably also want:<p><pre><code> set -o pipefail </code></pre> Otherwise, it only checks that the last command succeeds, so something like:<p><pre><code> ls *.ssjkfle | wc -l </code></pre> will actually continue as success despite the &quot;ls&quot; failing.

&#x27;set -o nounset&#x27; is a must have. I Just suffered this script from Samsung Printer setting Utility. sudo .&#x2F;uninstall wiped the &#x2F;opt<p><pre><code> DEST_PATH=&#x2F;opt&#x2F;$VENDOR&#x2F;$DEST_DIRNAME #remove destination VERSION=`cat &quot;$DEST_PATH&#x2F;bin&#x2F;.version&quot;` if rm -fr &quot;$DEST_PATH&quot;; then echo &quot;INFO: $APP_NAME (ver.$VERSION) has been uninstalled successfully.&quot; ...</code></pre>

Another useful capability I use to do cleanup is `trap`.<p><pre><code> function cleanup { ... } trap cleanup EXIT </code></pre> See more here: <a href="http://linux.die.net/Bash-Beginners-Guide/sect_12_02.html" rel="nofollow">http:&#x2F;&#x2F;linux.die.net&#x2F;Bash-Beginners-Guide&#x2F;sect_12_02.html</a>

Use:<p><pre><code> #!&#x2F;usr&#x2F;bin&#x2F;env bash </code></pre> Instead of:<p><pre><code> #!&#x2F;bin&#x2F;bash </code></pre> This makes the script more portable as you don&#x27;t rely on bash (or any executable) to be in &#x2F;bin.<p><a href="http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Shebang_(Unix)#Portability</a>

I&#x27;m glad this included the &quot;Signs you should not be using a bash script&quot; section. Bash is a very good solution for many cases, but it becomes downright unruly when dealing with a lot of string manipulation and more complex objects.

I love the very last list »Signs that you should not be using a bash script«. That should be a required part of every language&#x2F;tool introduction&#x2F;tutorial.<p>So very often people lose track of when to use what tools. (Although admittedly, so very often people are forced into some tools by external constraints.)

I found this web page, from the author of musl libc, very insightful:<p><a href="http://www.etalabs.net/sh_tricks.html" rel="nofollow">http:&#x2F;&#x2F;www.etalabs.net&#x2F;sh_tricks.html</a><p>Shell scripts are great, I use and write them every day (and quite advanced ones, too). But it&#x27;s very hard to make a shell script robust.<p>Unfortunately it&#x27;s hard to find a replacement that is stable and installed everywhere. Perl is pretty close. And python too, if you are careful about making your script compatible with all the different versions.

A link on HN about improving bash and it wasn&#x27;t instructions on how to install zsh. I&#x27;m pleasantly surprised :)

<p><pre><code> complete -r </code></pre> disables Bash &#x27;smart tab completion&#x27;, which in theory is a great idea ( use tab to complete arguments or only list files applicable to the program ) but which never seems to work properly for me.<p>Disabling it saves a lot of frustrated tab-banging.

Nice here document feature I have found recently is heredoc with pipe, e.g.<p><pre><code> cat &lt;&lt;REQUEST_BODY | { &quot;from&quot; : 0, &quot;size&quot; : 40 } REQUEST_BODY curl http:&#x2F;&#x2F;localhost -d @- </code></pre> It allows to pass heredoc text to standard input of next command.

are we going to get a better bash at one point? I&#x27;ve always felt like the only thing bash scripts are good at describing is I&#x2F;O redirection. But conditionals, dealing with variables, pretty much everything else is frustrating and error-prone<p>I use fish as my main shell and its slightly better, but just testing things on variables can be a huge mess.

I&#x27;d really recommend using `set -x` or `bash -x script` to sanity check all the commands and expected output.<p>See <a href="http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html" rel="nofollow">http:&#x2F;&#x2F;www.tldp.org&#x2F;LDP&#x2F;Bash-Beginners-Guide&#x2F;html&#x2F;sect_02_03...</a>

<i>Try moving all bash code into functions leaving only global variable&#x2F;constant definitions and a call to “main” at the top-level.</i><p>One of my main complaints with bash.. the file is evaluated in order - you can&#x27;t call a function on the line before it&#x27;s declared.<p>This fails:<p><pre><code> #!&#x2F;usr&#x2F;bin&#x2F;env bash bar=&#x27;bar&#x27; foofunction foofunction(){ echo &#x27;foo&#x27; echo $bar } </code></pre> Basically you have to write your entire script in reverse, and i&#x27;m unaware of a good way to get around it.

If you&#x27;d like to see a decently written piece of bash that incorporates many of these suggestions, check out pass, the standard unix password manager.<p>Project page: <a href="http://www.zx2c4.com/projects/password-store/" rel="nofollow">http:&#x2F;&#x2F;www.zx2c4.com&#x2F;projects&#x2F;password-store&#x2F;</a> Source: <a href="http://git.zx2c4.com/password-store/tree/src/password-store.sh" rel="nofollow">http:&#x2F;&#x2F;git.zx2c4.com&#x2F;password-store&#x2F;tree&#x2F;src&#x2F;password-store....</a>

Excellent, <i>bash the good parts</i>. More than 15 minutes though.<p>Googling <i>bashlint</i>, <i>shlint</i> turns up some discussion (bash -n, ksh -n, zsh -n, some github projects), but I doubt they cover this article&#x27;s specifics - though most (all?) of it could be automatically checked. I think <i>some</i> could be automatically added (e.g. <i>set -o nounset</i>) - perhaps a bash-subset (or coffeescript-style language) possible...

The author uses ${} a lot more than I see in most code. Is it helpful to always use the ${var} syntax instead of simply writing $var?<p>I can see universal application of ${} being advantageous in avoiding accidental &quot;$foo_bar where you meant ${foo}_bar&quot; situations, and ${} makes it clearer that you&#x27;re referencing a variable. The only cost would seem to be more typing.

I also like <a href="http://google-styleguide.googlecode.com/svn/trunk/shell.xml" rel="nofollow">http:&#x2F;&#x2F;google-styleguide.googlecode.com&#x2F;svn&#x2F;trunk&#x2F;shell.xml</a> but of course some things that work well for Google might not work for you.

&gt;&gt; This will take care of two very common errors: &gt;&gt; Referencing undefined variables (which default to &quot;&quot;) &gt;&gt; Ignoring failing commands<p>Better is subjective... About half my scripts depend on those features. For default arguments, and fail early.

There is no need for long set flags, e.g. use<p><pre><code> set -e </code></pre> and not:<p><pre><code> set -o err </code></pre> etc.

One thing I&#x27;ve liked is throwing ${PIPESTATUS[*]} at the front of my PS1.

Or you can just use Zsh, which is superior in any way to Bash. ;)