Hacker News Reader

Comment by chrsig | Hacker News Reader

I really wish bash could evolve...in particular around control flow, variable assignment, string interpolation, and arithmetic.

I love working with bash, but it has some footguns that really require an expert hand.

I know bash as-is will always be around for backwards compatibility with the god-knows-how-many scripts out there. It'd just be nice if there were a widely embraced path forward that kept the shell scripting spirit while shedding some of the unintuitive behaviors

View on HN

I gave up on bash (more precisely on bashisms. edit: and because of bashims) and moved to dash or whatever is at /bin/sh. If it can't be done with ash/dash then I look into Python or node or PHP or what fits the situation best.

I did the same. I believe the biggest selling point of shell over other scripting languages is its availability on so many platforms. Unfortunately bashisms have ruined the effort of writing a one-size-fits-all script. So I, too, moved to POSIX shell syntax for the small problems and another shell scripting language for the bigger problems.

Bash is very widely available. If you use bashisms like arrays, just use bash as the first line.

As the shebang (`#!`), I imagine you mean?

Yes, shebang.

Evolving bash, removing footguns, and providing a path forward is exactly what https://www.oilshell.org is about :)

It's run thousands of lines of unmodified shell AND bash scripts for years, and provides an upgrade path to a new language.

The new language is described here, and you can try it: https://www.oilshell.org/release/latest/doc/oil-language-tou...

I've gotten some great feedback on it, but it's not stable yet. You can still influence the direction of the language (join us on Zulip)

Latest release gives the status of the project: https://www.oilshell.org/blog/2023/03/release-0.14.2.html

As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash.

In shell and bash, "you're damned if you do set -e and damned if yuo don't"

However I believe we have done it: https://www.oilshell.org/release/0.14.2/doc/error-handling.h...

We simply provide options to make sure that every exit code is checked. That's really all. But shells do NOT do this. In fact the standard specifies that shells shouldn't, which has left people mystified for decades.

I've gotten good feedback about error handling and the rest of the changes. Again, you can try it right now if you want to verify that the footguns are indeed fixed.

> As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash.

Shameless plug: I've recently written a blog post about how set -e suddenly ceases to work when using function calls in flow control (what you refer to as "disabled errexit quirk"): https://snails.dev/posts/set-e.html

Your comment made me interested in Oil, thanks!

I think there is a place for a transpile to Bash language, which just adds some tiny bits to fix Bash's idiosyncrasis

Regarding the post topic, it's a shame bash hasn't embraced ksh93 getopts. This is enough to provide short and long options including help messages:

    usage='
      [-1]
      [+NAME?cmd - XXX Synopsis here]
      [s:sample?XXX Sample option with argument]:[MODE]
      [v:verbose?XXX Show progress]

      file ...'
    while getopts "$usage" _
    do
      typeset "opt_$_"="${OPTARG:-1}";;
    done
    shift OPTIND-1

Reply on news.ycombinator.com