Don'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:
This checks that the tput command exists (using the bash 'command' builtin rather than which(1) - surprisingly, which can't always be relied upon to be installed even on modern GNU/Linux systems), that stdout is a tty, and that the NO_COLOR env var is not set. If any of these conditions are false, a no-op tput function is defined.
This little snippet of setup lets you sprinkle tput invocations through your script knowing that it's going to do the right thing in any situation.
Be aware there's an escape character at the start of each of color string, which is the POSIX equivalent of $'\e'; Hacker News seems to cut out that escape character.
If you use tput a lot it's also worth caching the output, because invoking it for every single color change and reset can really add up. If you know you're going to use a bunch of colors up front you can just stuff them into vars
It’s a bit more complicated. POSIX shell != bash, for example the default shell (/bin/sh) on macOS is now zsh, on Ubuntu it’s dash. Bash may still be installed, but may be years older than 2024. At a certain point, you’re better off embracing a dependency that just does everything better, like Python or Oil shell, for example.
Why? Benefit? 10% of people hace problemas with colors. Depending on the terminal/background, you will produce bad/invisible output.
Any good typesetting book will tell you not to use colors.
This little snippet of setup lets you sprinkle tput invocations through your script knowing that it's going to do the right thing in any situation.