…cs.washington.edu/…/bash_style_guide.html

github.com/bahamas10/bash-style-guide

Choose whatever fits you

Google google.github.io/styleguide/shellguide.html

ShellCheck is a static analysis tool for bash/sh scripts - try it on your scripts. The README also shows some examples of what (not) to do.

The link to your project gives me a 404 btw, is it a private repository?

There is no single Bash standard to follow, only a few guidelines. One way you can check for some basic errors and formatting would be using an editor with support for Bash (in best case with a builtin LSP). At the end, you have to find your style and coding standards or adapt what others do if you want work with them or edit their files.

• Otherwise there is a well known tool for checking Bash files: www.shellcheck.net You can use it online and as a downloaded program on your local machine. After using shellcheck for a bit I got used to some of its conventions and recommendations, such as always wrapping variables like in ${variable} and some other things.
• Google has a coding style guide, but not everyone likes it: google.github.io/styleguide/shellguide.html
• Related is the Bash Reference Manual from GNU: www.gnu.org/software/bash/manual/bash.html Off course this is not a guide on how to style or program, but it helps in understanding how GNU does things.

BTW the mk-blog link is 404 for me.

github.com/bash-lsp/bash-language-server

• pretty much all editors support LSP these days

A yes, the fear of opensourcing.

Trust me, proprietary code is often total garbage because nobody looks at it.

I try to follow Bash strict mode. It can protect you from some foot shooting.

I’ve used shfmt in the past: github.com/patrickvane/shfmt

Don’t know about everyone else, but here are some of mine:

• Stick to posix compliance shell code, wherever possible
• Please wrap your variables with { }. Just please.
• Global variables being exported in all caps
• Local variables in lower case
• $() instead of ` `
• Comment anything complicated, comment what section, comment usage
• Include usage output if options are not recognized
• Use case instead of if / elif, where possible
• 80 characters or less per line, where possible
• HERE docs in designated section, marked by comment blocks
• Comment your functions immediately above it’s definition
• Add comment “#End of function Xyz” at line immediately below a function, with replacing Xyz with name of that function
• 2 space indentation
• Multi-line strings: First line open with quote and first line of string, followed by a backslash , subsequent lines properly indented and backslashed. Last line, properly indented and close quoted.
• Break up multiple piping of commands with |\ and a new line where it makes sense to look nice, assisting readability
• Echo what the script is doing once in a while if the user will be waiting for a while
• Please don’t do shar archives, or byte located binary extractions, make a script and a separate tarball - Helps a ton if we have to change it, like say… swapping out a bundled java runtime built for x86_64 with one for aarch64
• If the script will run for a very long time, check for tmux or screen and also the TMOUT variable… Give a warning to the user their connection might time out before the script is done if they don’t unset TMOUT, and try using tmux or screen to allow the script to continue in the background, even if you do get disconnected
• Make use of logger
• I try to organize a script this way: 1. Shebang, 2. Initial variable definitions, 3. Functions, 4. runtime execution code, which might be best outside of a function, and calling functions. 5. Clean-up (remove pid and lock files, tmp files, etc etc.)

Repos are archived by the maintainer, but I find these really helpful resources:

github.com/dylanaraps/pure-bash-bible github.com/dylanaraps/pure-sh-bible

If your bash script gets longer than 200 lines (including argument handling), use Python. I have to support bash APPLICATIONS at work and it’s a fucking nightmare to maintain.