Most bash scripts are very brittle because error handling is an afterthought. In this blogpost you'll learn about the easiest ways to gracefully catch and handle errors. Best practices and common pitfalls.
And sometimes, a function is better for readability, even if you use it only once. For example, from one of my bigger scripts (i should have done in python).
full_path() {
case "$1" in
/*) printf "%s\n" "${1%/}";;
*) printf "%s\n" "$PWD/${1%/}";;
esac
}
sanitize() {
basename "${1%.*}" \
|sed 's/[^A-Za-z0-9./_-]/ /g' \
|tr -s " "
}
proj_dir="$(full_path "$proj_dir")" # get full path
proj_name="$(sanitize "$proj_dir")" # get sane name
Code as documentation basically.
Right, about the last point: if your script grows over 200 loc despite being nicely formatted and all (if-else spaghetti needs more space too), consider going further in a real programming language.
Shell is really only glue, not much for processing. It quickly gets messy and hard to debug, no mather how good your debugging functions are.
Fully agree. Shell scripts quickly get ugly over 50 loc. Please avoid spaghetti code in shell scripts too. The usual
is ok once or twice. But if you have tens of them,
is more readable. Or leave the check entirely away if xyz reports the error too.
And please.do.functions. Especially for error handling. And also for repeated patterns. For example the above, if it’s always xyz, then something like
is more readable.
And sometimes, a function is better for readability, even if you use it only once. For example, from one of my bigger scripts (i should have done in python).
Code as documentation basically.
Right, about the last point: if your script grows over 200 loc despite being nicely formatted and all (if-else spaghetti needs more space too), consider going further in a real programming language.
Shell is really only glue, not much for processing. It quickly gets messy and hard to debug, no mather how good your debugging functions are.