I’m using a style guide along with the
shfmt tools to help me improve the quality and consistency of my shell scripts.
I’m doubling down on shell scripting, in particular Bash shell scripting. This is for many reasons, not least because I think that in the age of cloud and containers, shell environments are more important than ever. And what better shell than the Unix style shell; the design dates back decades but is still in my eyes one of the most wondrous things in tech even today, with its beautiful simplicity and its simple beauty.
While watching a live stream replay by Mr Rob, specifically Google Shell Scripting Guide, Yes, Yes, 1000 Times Yes!, I came across the Google Shell Style Guide and it’s succinct enough to digest in a single sitting, and well written enough to comprehend in that time, too.
I’ve decided to use this style guide as a general reference for my scripts and plan to implement changes to some of my existing scripts over time.
I discovered the
shellcheck shell script analysis tool recently and my goodness me has it made a significant impact on not only the quality of what I write, but also on my understanding of Bash shell syntax! It’s available as an online tool, but far more importantly as a command line tool that will highlight issues with your shell code. A linter, basically.
Moreover, it has a rich set of reference material in the wiki, including definitive pages for each of the errors it will emit. Here’s an example: SC1019 is the error code for “Expected this to be an argument to the unary condition” and there’s a reference page for it here: SC1019.
I use Vim as my primary editing environment and use the Asynchronous Linting Engine (ALE) as a key plugin. This means, that without me lifting a finger,
shellcheck will be used asynchronously, live while I’m editing, to show me issues.
If you’re writing shell scripts, get
shellcheck installed and wired up to your editor now.
My son Joseph used to write a lot of Go, and I was fascinated by the philosophy of what the
gofmt formatting tool represented. Go programmers all expected code to be formatted the same way via this tool, and it’s natural for them to have their code (re)formatted when they save it in the editor. I know that this is anathema to some programmers, which is why it caught my eye.
There are formatters for other languages that work this way now (and I’m sure there were before, too) such as
rustfmt (used by Mr Rob, which is what gave me the idea) and there’s a version for shell scripts called
shfmt, described as “a shell parser, formatter and interpreter”.
Having experimented with the
shfmt options, I ended up choosing a few that would help me stay close to the style guide:
||indent with two spaces|
||binary ops like && and | may start a line|
||switch cases will be indented|
||redirect operators will be followed by a space|
I added some new configuration to tell Vim to use this
shfmt tool with these options, to automatically format any shell source on save. This means that I can get my script content automatically formatted without thinking about it, in the same way Go programmers enjoy.
This is what that configuration addition looks like right now:
fun! s:FormatBashScripts() if getline(1) =~# '^#!.*bash' && executable('shfmt') %!shfmt -i 2 -bn -ci -sr - endif endfun autocmd BufWritePre * call s:FormatBashScripts()
The reference to
getline is to check that the shebang denotes a Bash shell script and the reference to
executable prevents errors occurring if I’m on a machine where
shfmt is not available. The key part is this:
%!shfmt ... which passes the entire buffer contents through the invocation of
shfmt as if it were a filter, replacing the contents with whatever
I guess it almost goes without saying that the significance of how this works – using
shfmt as a filter to pass the content through, via STDIN and STDOUT, following one of the key Unix shell philosophies – is not lost on me.
And remember folks, #TheFutureIsTerminal!