Techniques I use to create a great user experience for shell scripts

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=''
      COLOR_RED=''
      COLOR_GREEN=''
      COLOR_BLUE=''
    else
      COLOR_RESET=''
      COLOR_RED=''
      COLOR_GREEN=''
      COLOR_BLUE=''
    fi

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

  RED=$(tput setaf 1)
  GREEN=$(tput setaf 2)
  RESET=$(tput sgr0)

There should just be a command for this. Like echo with a color flag that does something if you’re in a tty.

[dead]

Addendum after reading the script:

* #!/bin/bash instead of #!/usr/bin/env bash

* [ instead of [[

* -z instead of actually checking how many arguments you got passed and trusting the end user if they do something weird like pass an empty string to your program

* echo instead of printf

* `print_and_execute sdk install java $DEFAULT_JAVA_VERSION` who asked you to install things?

* `grep -h "^sdk use" "./prepare_$fork.sh" | cut -d' ' -f4 | while read -r version; do` You're seriously grepping shell scripts to determine what things you should install?

* Unquoted variables all over the place.

* Not using mktemp to hold all the temporary files and an exit trap to make sure they're cleaned up in most cases.

BOFH much? It’s not as if this script is going to be used by people that have no idea what is going to happen. It’s a script, not a command.

Your tone is very dismissive. Instead of criticism all of these could be phrased as suggestions instead. It’s like criticising your junior for being enthusiastic about everything they learned today.

> 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?

I would argue pipefail and set -e are much more reasonable defaults to take.

It's not that bad.

Another way to look at this is to chill out, it's a neat article and sometimes we write low stakes scripts just for ourselves on one machine.

The colors topic is really bad! I like to use blue backkround in my terminal, which breaks the output of that stupid scripts. DO NOT USE COLORS.

I find shellcheck to be a bit of a nuisance. For simple one-shot scripts, like cron jobs or wrappers, it's fine. But for more complicated scripts or command line tools, it can have a pretty poor signal-to-noise ratio. Not universally, but often enough that I don't really reach for it anymore.

In truth when I find myself writing a large "program" in Bash such that shellcheck is cumbersome it's a good indication that it should instead be written in a compiled language.

Always fun trying to read errors in a CI build and they are full of [[

shellcheck is an option for helping you creat a good user experience by guessing against common errors we all make (out of a mix of laziness, bad assumptions, being in a rush, or just only thinking about the happy paths), but it isn't directly creating a great user experience and there are other methods to achieve the same thing.

You took the words right out of my mouth.

Or what if I use red background?!

You may like bash-modules then: https://github.com/vlisivka/bash-modules/tree/master/bash-mo...

Gotta draw a line somewhere

The following check for gtimeout means that other OSs that don't have the expected behaviour in either command won't break the script, you'll just get a warning message that isn't terribly relevant to them (but more helpful than simply failing or silently running without timeout/gtimeout. Perhaps improving that message would be the better option.

Though for that snippet I would argue for testing for the command rather than the OS (unless Macs or some other common arrangement has something incompatible in the standard path with the same command name?).

The worst part is that if you're not running Linux but have a perfectly working 'timeout' command, the script will ignore it and fail.

Eh. It’s true for most, and if not, it’s probably still a *BSD, so there’s a good chance that anything written for a Mac will still work.

That said, I’ve never used any of the BSDs, so I may be way off here.

> shell scripts are the wrong solution for anything over ~50 lines of code.

I don't think LOC is the correct criterion.

I do solve many problems with bash and I enjoy the simplicity of shell coding. I even have long bash scripts. But I do agree that shell scripting is the right solution only if

    = you can solve the problem quickly 
    = you don't need data structures
    = you don't need math 
    = you don't need concurrency

Try running a 6 month old Python project that you haven't run in that time and report back.

Meanwhile, 10 year old Bash scripts I've written still run unmodified.

Winner by a mile (from a software-longevity and low-maintenance perspective at least): Bash

Some of us enjoy the masochism, thank you very much.

Deno is great for writing quick scripts: https://deno.com/learn/scripts-clis

Bun has similar features: https://bun.sh/docs/runtime/shell

I draw the line after a single if.

I agree with the general idea, but 1) LOC is not a good metric 2) I would immediately take off the list Python and Typescript, and anything what is compiled, leaving the list much shorter

I draw the line at around 300 lines.

> "It causes your script to die unexpectedly with no output."

Oh? I don't observe this behavior in my testing. Could you share an example? AFAIK, if you don't capture stderr, that should be passed to the user.

> "Instead, just check $? and..."

I agree that careful error handling is ideal. However, IMO it's good defensive practice to start scripts with "-e" and pipefail.

For many/most scripts, it's preferable to fail with inadequate output than to "succeed" but not perform the actions expected by the caller.

I like:

    readonly SCRIPT_SRC="$(dirname "${BASH_SOURCE[${#BASH_SOURCE[@]} - 1]}")"
    readonly SCRIPT_DIR="$(cd "${SCRIPT_SRC}" >/dev/null 2>&1 && pwd)"
    readonly SCRIPT_NAME=$(basename "$0")

I've been using

script_dir="$(dirname "$(realpath "$0")")"

Hasn't failed me so far and it's easy enough to remember

Why would you change a shell (sh?) script into a Bash script? And why would you change [[ into [ expressions, which are not Posix, as far as I remember? And why make the distinction for numeric variablesand not simply make the usage the same, consistent for everything? Does it also leave away the double quotes there? That even sounds dangerous, since numeric variables can contain filenames with spaces.

Somehow whenever people dance to the Google code conventions tune, I find they adhere to questionable practices. I think people need to realize, that big tech conventions are simply their common debominator, and not especially great rules, that everyone should adopt for themselves.

I also hate bash scripting, and as far as Unix shell go, bash is among the best. So many footguns... Dealing with filenames with spaces is a pain, and files that start with a '-', "rm -rf" in a script is a disaster waiting to happen unless you triple check everything (empty strings, are you in the correct directory, etc...), globs that don't match anything, etc...

But interactively, I much prefer Unix shells over PowerShell. When you don't have edge cases and user input validation to deal with, these quirks become much more manageable. Maybe I am lacking experience, but I find PowerShell uncomfortable to use, and I don't know if it has all these fancy interactive features many Unix shell have nowadays.

What you are saying essentially is that PowerShell is a better programming language than bash, quite a low bar actually. But then you have to compare it to real programming languages, like Perl or Python.

Perl has many shell-like features, the best regex support of any language, which is useful when everything is text, many powerful features, and an extensive ecosystem.

Python is less shell-like but is one of the most popular languages today, with a huge ecosystem, clean code, and pretty good two-way integration, which mean you can not only run Python from your executable, but Python can call it back.

If what you are for is portability and built-in commands, then the competition is Busybox, a ~1MB self-contained executable providing the most common Unix commands and a shell, very popular for embedded systems.

Bash also has a built-in to validate parameters; it’s called test, and is usually called with [], or [[]] for some bash-specifics.

Re: non-standard tools, if you’re referring to timeout, that’s part of GNU coreutils. It’s pretty standard for Linux. BSDs also have it from what I can tell, so it’s probably a Mac-ism. In any case, you could just pipe through sleep to achieve the same thing.

> …inputs and outputs are strongly typed objects

And herein is the difference. *nix-land has everything as a file. It’s the universal communication standard, and it’s extremely unlikely to change. I have zero desire to navigate a DB as though it were a mount point, and I’m unsure why you would ever want to. Surely SQL Server has a CLI tool like MySQL and Postgres.

And for anyone who might be open to trying powershell, the cross platform version is pwsh.

Pythonistas who are used to __dir__ and help() would find themselves comfortable with `gm` (get-member) and get-help to introspect commands.

You will also find Python-style dynamic typing, except with PHP syntax. $a=1; $b=2; $a + $b works in a sane manner (try that with bash). There are still funny business with type coercion. $a=1; $b="2"; $a+$b (3); $b+$a ("21");

I also found "get-command" very helpful with locating related commands. For instance "get-command -noun file" returns all the "verb-noun" commands that has the noun "file". (It gives "out-file" and "unblock-file")

Another nice thing about powershell is you can retain all your printf debugging when you are done. Using "Write-Verbose" and "Write-Debug" etc allows you to write at different log levels.

Once you are used to basic powershell, there are bunch of standard patterns like how to do Dry-Runs, and Confirmation levels. Powershell also supports closures, so people create `make` style build systems and unit test suites with them.

The big problem with trying to move on from BASH is that it's everywhere and is excellent at tying together other unix tools and navigating the filesystem - it's at just the right abstraction level to be the duct tape of languages. Moving to other languages provides a lot more safety and power, but then you can't rely on the correct version being necessarily installed on some machine you haven't touched in 10 years.

I'm not a fan of powershell myself as the only time I've tried it (I don't do much with Windows), I hit a problem with it (or the object I was using) not being able to handle more than 256 characters for a directory and file. That meant that I just installed cygwin and used a BASH script instead.

I am Microsoft hater. I cannot stand Windows and only use Linux.

PowerShell blows bash out of the water. I love it.

My issue with powershell is that it’s niche language with a niche “stdlib” which cannot be used as general purpose. The same issue I have with AHK. These two are languages that you use for a few hours and then forget completely in three weeks.

Both of them should be simply python and typescript compatible dlls.

You can “cd” into IIS, Exchange, and SQL and navigate them like they’re a drive. Try that with bash!

This exists.

   PowerShell can be embedded into a process as a library... and used to build an entire GUI that just wraps the CLI commands.

Bash is crap and powershell an abomination with a few good ideas.

fish, Python, and oilshell (ysh) are ultimately on better footing.

Even worse, it mimics it poorly, hardcoding the PS4 to the default.

The author could also consider trapping debug to maybe be selective while also making it a little more automatic.

Even 4 can be generalized to "be deliberate about what you do with a failed function call (etc) - does it exit the command? Log/print an error and continue? Get silently ignored? Handled?"

Or $NO_COLOR, per https://no-color.org

Thanks! I've always edited the script adding a `set -x` at the top. Never occurred to me that I the shell of course had a similar startup flag.

It happens to the best of us

https://github.com/ValveSoftware/steam-for-linux/issues/3671

Also, you'd want to put in a double dash to signify the end of arguments as otherwise someone could set VAR="--no-preserve-root " and truly trash the system. Also, ${VAR} needs to be in double quotes for something as dangerous as a "rm" command:

    rm -rf -- "${VAR}"/*

`exit` will work as expected in Python 3.13: https://docs.python.org/3.13/whatsnew/3.13.html#whatsnew313-...

Yes. I'd be surprised if exit without parentheses quit the interactive shell when it doesn't quit a normal python script.

Bad timing, this is changed in Python 3.12.

Still I’ve always used Ctrl+D, which works everywhere unixy.

On the one hand, being generous in your inputs is always appreciated. On the other hand, the fact that both exit and quit will terminate ruby means the answer to "how do I quit ruby" now has two answers (technically 4 because `quit()` and `exit()` also work, and if we're talking about "least surprise" if you accept "exit" and "quit", why not also "bye" or "leave" or "close" or "end" or "terminate".

Python might be surprising, but in this example, it's only surprising once, and helpful when it surprises you. Now you know quitting requires calling a function and that function is named exit() (although amusingly python3 anyway also accepts quit()). And being fully pedantic it doesn't know what you mean, it is assuming what you mean and making a suggestion, but that's not the same as knowing.

From here on I'm not arguing the point anymore, just recording some of the interesting things I discovered exploring this in response to your comment:

You can do this in python (which IMO is surprising, but in a different way):

  ```
  >>> quit
  Use quit() or Ctrl-D (i.e. EOF) to exit
  >>> quit=True
  >>> quit
  True
  >>> quit()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'bool' object is not callable
  >>> exit()
  ```

`exit` is a class isntance according to type. So we should be able to create something similar, and indeed we can:

  ```
  >>> class Bar:
  ...   def __repr__(self):
  ...     return "Type bar() to quit!"
  ...   def __call__(self):
  ...     print("I quit!")
  ...
  >>> bar = Bar()
  >>> bar
  Type bar() to quit!
  >>> bar()
  I quit!
  >>>
  ```

  ```
  >>> class SuperExit:
  ...   def __init__(self, real):
  ...     self.real_exit=real
  ...   def __repr__(self):
  ...     print("Exiting via repr")
  ...     self.real_exit()
  ...   def __call__(self):
  ...     print("Exiting via call")
  ...     self.real_exit()
  ...
  >>> exit = SuperExit(exit)
  >>> exit
  Exiting via repr
  ```

this actually completely turned me off from python when I first encountered it. I was like... "the program KNEW WHAT I WAS TRYING TO DO, and instead of just DOING that it ADMONISHED me, fuck Python" LOL

The proliferation of Python has only made my feelings worse. Try running a 6 month old Python project that you haven't touched and see if it still runs. /eyeroll

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 small, portable scripts I try to stick to POSIX standards (shellcheck helps with this) instead of bash or python.

For bigger scripts, typically I'll reach for python or Typescript. However, that requires paying the cost of documenting and automating the setup, version detection, etc. and the cost to users for dealing with that extra setup and inevitable issues with it. Compiled languages are the next level, but obviously have their own challenges.

Depends on how long you want the script/program to be usable.

Try running a twenty year old BASH script versus a python programme on a new ARM or RISC-V chip.

Or, try running BASH/python on some ancient AIX hardware.

can you share it?

Sounds like a cool setup! Did you write it up somewhere publicly?

I also use VMs (qemu microvms) based on docker images for development.

The form you propose runs `command`, which may have undesired side-effects. I always thought `which` to be standard, but TIL `command` (sh builtin) is[0].

[0]: https://hynek.me/til/which-not-posix/

Glow is awesome.

He says in the article. 'Set +e' prevents any error in a fork blitzing the whole script.