Shell script best practices, from a decade of scripting things
1–10 of 500 posts
Re: Shell script best practices, from a decade of scripting things
#2Personally I try to stick with POSIX sh (testing with dash), if I need anything fancier, I reach for Perl or Python.
Re: Shell script best practices, from a decade of scripting things
#3Timing couldn't be any better. Been getting serious about bash/zsh scripting lately.
Re: Shell script best practices, from a decade of scripting things
#4These could be linting rules for bash script files.
Re: Shell script best practices, from a decade of scripting things
#5Personally I try to stick with POSIX sh (testing with dash), if I need anything fancier, I reach for Perl or Python.
POSIX sh also yields better performance, provided you're using dash.
Re: Shell script best practices, from a decade of scripting things
#6For systems that I control myself I much prefer to avoid Bash/sh. They’re just to clunky. And if I need to use them, I try to do as little as possible in order to make it more robust.
Case in point: Declaring an array. IMHO, it’s just not ergonomic at all. Especially not in sh/dash.
Re: Shell script best practices, from a decade of scripting things
#7Missing: When using "set -o pipefail" you should also catch any non-zero return codes that you want to accept, e.g., "{ grep -o pattern file || true ; } | sed pattern" to let the command continue (if desired) to execute even if pattern isn't found.
Re: Shell script best practices, from a decade of scripting things
#8These could be linting rules for bash script files.
If you need to follow these rules your script probably shouldn’t be written as a shell script.
Re: Shell script best practices, from a decade of scripting things
#9I didn't know many of these! Thanks
Re: Shell script best practices, from a decade of scripting things
#10Shell scripts are great for executing a series of commands with branching and looping logic around them.
As soon as output needs to be parsed — especially when it’s being fed back into other parts of the script — it gets harder. Handling errors and exceptions is even more difficult.
Things really fall down on modularity. There are tricks and conventions: for example you can put all functions to do with x in a file called lib/x.sh, prefix them all with x_, and require that all positional parameters must be declared at the top of each function with local names.
At that point though, I would rather move to a language with named parameters, namespaced modules, and exception handling. In Python, it’s really easy to do the shell bits with:
def sh(script):
subprocess.run(
[‘sh’, ‘-c’, script, ‘--‘, *args],
check=True,
)