GNU Guile [0] is pretty cool.

[0] https://www.gnu.org/software/guile

The most interesting ones I’ve come across are:

- Elvish https://elv.sh

- Murex https://murex.rocks

- Oil https://oils.pub

I write a lot of JS/TS for my day job, so zx (https://github.com/google/zx) has been a nice tool for bash scripts that start getting a little too complex.

I think it kinda was one of Perl’s goals at the time. But the syntax is rather unusual.

I found https://github.com/cosmos72/schemesh lately and - once you accept LISPism - is pretty nice to use.

Have you tried NGS (https://ngs-lang.org)? I found its approach of giving you that power while remaining shell-focused to be very refreshing.

> Wondering what others have found to address this. Or if they just stuck with Bash, since it's just not going away anytime soon.

If you're familiar with Python, give xonsh (https://xon.sh/) a go. It's a Bash-like shell but the syntax is Python. It has the same ease of writing shell scripts as Bash does, sans the insane language.

Been using it since 2018.

Lua is my favourite, too, but i found writing in awk to be more pragmatic.

We've transitioned all of our Bash scripts over to Ruby and are pretty happy with it. We almost exclusively use only Ruby's standard library. 'fileutils' and 'rake' have a bunch of nice functions to replace Bash scripts.

See, FileUtils for things like rm_rf, rake provides sh which can execute commands, then there's FileList and Pathname. It even comes with its own template engine (erb) if you need that. Regexes as first class citizens are awesome for shell scripting.

I can also recommend using optprase + ostruct for commandline argument parsing.

I moved to using perl first, but these days I'm mostly using python except where regular expressions are needed in which case I'm still using perl

Same but I found it a really bad choice for a Bash replacement

You have to reinvent the wheel every other day since the standard library doesn't come with much included

I'm an incredibly happy user of nushell, which brings all the best features of other shells terse pipelining syntax and all the best features of more well designed scripting languages (functions, modules, lexical scope, data structures, completely optional types) in one awesome package that also comes with editor (LSP) support and excellent documentation

https://www.nushell.sh/

(The intro page may be a bit misleading. You can freely mix-and-match existing, unstructured as well as nushell-built-in structured commands in the pipeline, as long as you convert to/from string streams - its not mandatory to use the structured built-ins. For example if an existing cli tool has json output, you can use `tool | from json` to turn it into structured data. There are also commands like `detect columns` that parses classic column output, and so on - the tools to mix-and-match structured and unstructured data are convenient and expressive)

Some highlights:

- automatic command line arguments and help by defining a main function and adding comments to each argument - e.g. https://github.com/nushell/nushell/discussions/11969

- run commands with controlled parallelism: https://www.nushell.sh/commands/docs/par-each.html

- easy parsing of raw input https://www.nushell.sh/commands/docs/parse.html

- support for a wide variety of data formats https://www.nushell.sh/commands/categories/formats.html

- built-in support for talking to SQLite databases: https://www.nushell.sh/book/loading_data.html#sqlite

edit: it looks like Mitchell Hashimoto was recently impressed too https://x.com/mitchellh/status/1907849319052386577 - rich functional programming library that blends with pipeline syntax https://www.nushell.sh/book/nushell_map_functional.html

Addendum: Its not my login shell. I run it ad-hoc as soon as the command pipeline i'm writing starts getting too complicated, or to write scripts (which of course can be run from outside nushell too, so long as they have the correct shebang)

NetBSD's base system includes both the best scripting shell, ash, and lua. Thankfully, no python, no startup cost.

if bash/sh scripts get too long (or long-lived), I switch to python when possible.

As a minor example, I hate having to remember (or explain) ${var##pattern}

It is useful for manipulating paths, but it is cryptic.

in comparison, something like:

  newfile = os.path.join(newpath, os.path.basename(oldpath)) 

Also, argparse is the best.

+1 for shellcheck recommendation, it's fairly essential if you want to be good at Bash

2025 update of this 2006 presentation has a better title, https://news.ycombinator.com/item?id=43714928

  Seat Belts and Airbags for bash

Aren't TCL and Perl stringly-typed scripting languages?

> This statement primarily applies to existing stringly-typed scripting languages

IMO it applies to all languages. Fancy language features usually make for poor maintainability, e.g. metaprogramming.

I have followed the advice in this story for all my scripts. They are just better interfaces to collection of tools that already exists, not new tools. I write them when the subproblems are already solved by specific programs and the coordination does not require complex data transformation.

Great presentation. I've been writing bash for waaaay too long, and, while I nodded and said yup, yup, a few times, I also learned some new tricks, so thank you!

The social graces having been observed, if you were to update this presentation to reflect modern bash, and especially reference variables, what would be your top 3 additions?

(I am a big fan of reference variables. They make it possible to, among other things, do some funky things that would otherwise require liberal use of eval, which I eschew. Figuring out how to ensure that the target of a reference variable was in fact an associative array while running under `set -u` was a trick of which I am proud. Note: what I did works and isn't totally ugly, there may be a better way, YMMV, IANAL, etc.)

Second Q, if you will permit: Given the memory leaks in associative array management that have been corrected over the last several years, what are your thoughts on a) whether or not bash should have ever gone that route, and, potentially more controversially, b) the current state of bash maintenance?

(I'm not going to ask about embedding multiple levels of ${...#...} or ${...#...}, because even if it worked, readability would tend to 0 very, very quickly. I'd rather be repetitive and readable and maintainable. Well. Most of the time.)

Is there an https link to this pdf? So rare to see http nowadays.

Thanks for carrying a 20 year torch on bash maintainability!

> it'd sure be nice to have the presentation on video form

March 2025 presentation by the same author, "Seat belts and Airbags for bash"

slides: http://uniforumchicago.org/slides/bash_2025-03-25.pdf

video (87m): https://www.youtube.com/watch?v=DvDu8_A2uhs

Not down, just not on https. http link works just fine, but browser redirects to https by default.

You will like the final version of the traperr ERR function. It looks to create a "stack trace" type dump of where you are in the script when it fails.

See it here: https://github.com/pottmi/stringent.sh

This trope comes up every time bash is mentioned, without fail. Unless your team enjoys reading this, then no, a general purpose programming language is not a good replacement for what is effectively a "subprocess orchestration language":

  from subprocess import run, PIPE
  home = os.getenv("HOME")
  try:
    os.chdir(f"{home}/dev")
  except FileNotFoundError:
    sys.exit(1)
  out = run(("git ls-remote https://github.com/%(repo)s refs/tags/%(tag)s"
            % {"repo": shlex.quote("myorg/myrepo"), "tag": shlex.quote("v1.2.3+deadbeef")}).split(" "),
            stdout=PIPE, stderr=PIPE)

That's not even getting into the pty portion, where the progress of the output isn't visible until the end of it, which is terrible DX

IMO, using something like Python or JavaScript is a good idea if any of the following criteria is met:

- Working with data more than executing other binaries

- Dominant data processing path is structured (e.g. JSON, XML, binary)

- Script requires complex flow control to be manageable (e.g. functions, if, case)

- Shell UI requirements that involve handling command-line options

- You find yourself going _deep_ into the docs for jq to get the job done

.

Conversely, BASH is better under the following circumstances:

- Orchestrating other binaries the majority of the time

- Simple jobs that work with newline-separated text lines, or all data can be comfortably "stringly typed"

- Launching and job control for other processes

- You just need to glue some other shell commands and binaries together

- Are just manipulating shell environment vars, or providing a custom user shell (e.g. Python venv `activate`)

- Need to wrap a CLI tool in a simple way

.

The minute you have to reach for BASH arrays, case statements, math... stop everything and seriously consider using a language that has stronger support for all that.

don't listen to the others.

yes. I think if you find yourself dropping to sed/grep/awk/find too much, switch to python.

The language itself imho seems more readable. Strings, lists and hashes seem better especially when you choke on quoting.

And the python standard library makes a huge difference when you grow above "simple". I love argparse for readable arguments with help. os.path lets you manipulate paths and filenames in a readable and robust way. you can read and write json, csv and more. datetime lets you manipulate dates and times.

yes, unless you need it to run somewhere that you know only has bash.

historically, I did not write a lot of code in python - but since an LLM can, now i especially have no problem doing more scripts in it. it's so much more scalable than bash and pretty much ubiquitous.

That. Is. Evil.

Nuke it from orbit, or something like that.

Choice of scripting shell is personal preference. Preferences may differ amongst computer owners. For example, I prefer NetBSD sh. On Linux I use a slightly modified Dash.

As for the preferences of others, I note the default scripting shell on the largest Linux distributions is not Bash. It is of course Dash, which is derived from NetBSD sh, which is derived from the Almquist shell (ash). Indeed, ash is a popular choice for scripting. It is smaller and faster than Bash.

Any recommendation on small shells? ash?

It is not how to code in bash, it is how to avoid the bash pitfalls.

The slides look to me a lot closer to laTex beamer than PowerPoint.

Edit: I take it back, the PDF metadata says:

Creator: PowerPoint

Producer: Mac OS X 10.4.8 Quartz PDFContext

Maybe it was written on OpenOffice or something and saved to ppt(x)? The linked file is PDF though.

Thanks to WSL, bash is ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶o̶n̶ shipped with Windows.