> Strategic Error Handling with "set -e" and "set +e"
I think appending an explicit || true for commands that are ok to fail makes more sense. Having state you need to keep track of just makes things less readable.
Techniques I use to create a great user experience for shell scripts
271–280 of 281 posts
Re: Techniques I use to create a great user experience for shell scripts
#272Don't output ANSI colour codes directly - your output could redirect to a file, or perhaps the user simply prefers no colour. Use tput instead, and add a little snippet like this to the top of your script: command -v tput &>/dev/null && [ -t 1 ] && [ -z "${NO_COLOR:-}" ] || tput() { true; } This checks that the tput command exists (using the bash 'command' builtin rather than which(1) - surprisingly, which can't alwa…
Yes and even better for faster speed and greater shell compatibility for basic colors, you can use this POSIX code: if [ -t 1 ] && [ -z "${NO_COLOR:-}" ]; then COLOR_RESET='[0m' COLOR_RED='[31m' COLOR_GREEN='[32m' COLOR_BLUE='[34m' else COLOR_RESET='' COLOR_RED='' COLOR_GREEN='' COLOR_BLUE='' fi For more about this see Unix Shell Script Tactics: https://github.com/SixArm/unix-shell-script-tactics/tree/mai... Be a…
You should also at least check for TERM=dumb which is an older convention than NO_COLOR.
Re: Techniques I use to create a great user experience for shell scripts
#273Earlier quoted context omitted.
Glow is awesome.
No. Glow connects to internet servers, screw that.
Please point me to the exact place in the source code where it does that:
Re: Techniques I use to create a great user experience for shell scripts
#274Earlier quoted context omitted.
No. Glow connects to internet servers, screw that.
Oops, I actually meant Gum, not Glow. Different project from the same folks. That said, I use Glow to render markdown sometimes. When and how does it connect to internet servers?
I think the person you're responding to is FOS but anyone can audit the source code to find such a thing: https://github.com/charmbracelet/glow
Re: Techniques I use to create a great user experience for shell scripts
#275Earlier quoted context omitted.
Yes and even better for faster speed and greater shell compatibility for basic colors, you can use this POSIX code: if [ -t 1 ] && [ -z "${NO_COLOR:-}" ]; then COLOR_RESET='[0m' COLOR_RED='[31m' COLOR_GREEN='[32m' COLOR_BLUE='[34m' else COLOR_RESET='' COLOR_RED='' COLOR_GREEN='' COLOR_BLUE='' fi For more about this see Unix Shell Script Tactics: https://github.com/SixArm/unix-shell-script-tactics/tree/mai... Be a…
You should also at least check for TERM=dumb which is an older convention than NO_COLOR.
Good point, you're right. Added. Thank you.
Re: Techniques I use to create a great user experience for shell scripts
#276Earlier quoted context omitted.
> pipefail when nothing is being piped (pipefail is not a "fix" it is an option I think it’s pretty good hygiene to set pipefail in the beginning of every script, even if you end up not using any pipes. And at that point is it that important to go back and remove it only to then have to remember that you removed it once you add a pipe?
Pipefail is not a fix. It is an option. It makes sense sometimes, it does not make sense other times. When you are using a pipeline in a script where you care about error handling then you should be asking yourself exactly what kind of error handling semantics you expect the pipeline to have and set pipefail accordingly. Sometimes you should even be using PIPESTATUS instead.
It’s an option and one that should probably have been on by default together with -e.
It’s not so much about error handling. It’s more about not executing all sorts of stuff after something fails.
Re: Techniques I use to create a great user experience for shell scripts
#277Earlier quoted context omitted.
No. Glow connects to internet servers, screw that.
Please point me to the exact place in the source code where it does that: https://github.com/charmbracelet/glow
https://github.com/charmbracelet/glow/issues/172
https://github.com/charmbracelet/glow/issues/615
But it looks like they finally removed that code a few months ago: https://github.com/charmbracelet/glow/pull/619
Re: Techniques I use to create a great user experience for shell scripts
#278Earlier quoted context omitted.
Please point me to the exact place in the source code where it does that: https://github.com/charmbracelet/glow
https://github.com/charmbracelet/glow/issues/172 https://github.com/charmbracelet/glow/issues/615 But it looks like they finally removed that code a few months ago: https://github.com/charmbracelet/glow/pull/619
yeah, looks like they had a "secure markdown stashing feature" at some point which is a cool way to do usage tracking while claiming you're offering a useful feature... and then people weren't fooled.
I'm fine with it
Re: Techniques I use to create a great user experience for shell scripts
#279I'd add, in each my Bash scripts I add this line to get the script's current directory: SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd ) This is based on this SA's answer: https://stackoverflow.com/questions/59895/how-do-i-get-the-d... I never got why Bash doesn't have a reliable "this file's path" feature and why people always take the current working directory for granted!
I've been using script_dir="$(dirname "$(realpath "$0")")" Hasn't failed me so far and it's easy enough to remember
Read the answers and comments from the SO threads. It won't always work for other people in other context.
Re: Techniques I use to create a great user experience for shell scripts
#280Let's normalize using python instead of bash
Using what version of python? How will you distribute the expected version to target machines? python has its place, but it's not without its own portability challenges and sneaky gotchas. I have many times written and tested a python script with (for example) 3.12 only to have a runtime error on a coworker's machine because they have an older python version that doesn't support a language feature that I used. For sm…
> Using what version of python? How will you distribute the expected version to target machines?
Let's focus on solving this then. Because the number of times that I've had to do surgery on horrible bash files because they were written for some platform and didn't run on mine...