Alternatives Don’t Need To Be Bashed

By default, bash is the most popular command language simply because it’s included in most *nix operating systems. Additionally, people don’t tend to spend a lot of time thinking about whatever their computer uses for scripting as they might for other pieces of software like a word processor or browser. If you are so inclined to take a closer look at this tool that’s often taken for granted, there are a number of alternatives to bash and [monzool] wanted to investigate them closely.

Unlike other similar documentation that [monzool] has come across where the writers didn’t actually use the scripting languages being investigated, [monzool] is planning to use each of these and accomplish specific objectives. This will allow them to get a feel for the languages and whether or not they are acceptable alternatives for bash. Moving through directories, passing commands back and forth, manipulating strings, searching for files, and manipulating the terminal display settings are all included in this task list. A few languages are tossed out before initial testing even begins for not meeting certain specific requirements. One example is not being particularly useful in [monzool]’s preferred embedded environments, but even so there are enough bash alternatives to test out ten separate languages.

Unfortunately, at the end of the day none of the ten selected would make a true replacement for bash, at least for [monzool]’s use case, but there were a few standouts nonetheless. Nutshell was interesting for being a more modern, advanced system and [monzool] found Janet to be a fun and interesting project but had limitations with cross-compiling. All in all though this seemed to be an enjoyable experience that we’d recommend if you actually want to get into the weeds on what scripting languages are actually capable of. Another interesting one we featured a while back attempts to perform as a shell and a programming language simultaneously.

20 thoughts on “Alternatives Don’t Need To Be Bashed

    1. yeah that’s what i think of as “alternative to bash”. i love bash for interaction but when i’m writing a shell script i’m glad /bin/sh links to a more minimal posix shell by default on debian these days. today, it’s dash. it reminds me not to use {curly,brace} alternative lists and backtick execution piped to parameters and [ brackets as an alternative to test ].

        1. backtick turned out to be a hackaday markup :) it’s the backwards apostrophe, it means take the output of the enclosed command and parse it as if it was commandline parameters to the outer command. it’s a shortcut for $(xxx). i honestly don’t know how widely supported / standardized it is but i am pretty sure i’ve run into an environment where it didn’t work (not sure if $(xxx) works everywhere either)

    2. I wholeheartedly agree. I run into far too many scripts that assume that /bin/sh is bash.

      If I’m in a hurry I usually change “#!/bin/sh” to “#!/usr/bin/env bash” to make sure that the script is run through bash.

  1. Novel shells always sound interesting, until you remember that all the other computers in the world will still be using bash (at best). It’s like, you might feel you express yourself better in Welsh, but that’s not helpful if you live in Iowa.

    I think we’re probably stuck with bash now – it’s an unfortunate side effect of computers getting good enough that no one’s reinventing them from scratch any more.

    1. There’s a difference between bash (language) and bash (executable). Like the other post above, scripts intended for distribution should never be written using bash extensions. Bash is pretty huge compared to the tinier alternatives: busybox’s dash-equivalent is like 80k.

  2. For my part, I’m using Bash or zsh when I must, because that’s what you get in Unix-likes nowadays.

    The rest of the time, it’s rc, specifically the version from plan9port.

    What’s the functional difference? Not much! But I can keep all of rc in my head, and Bashisms still occasionally get me. There’s something to be said for using tools that make you swear less often.

  3. In theory POSIX is the correct answer. Also, shell scripts is one of those things that AI probably is already better than most humans. Just feed the system specs and tools available and provide the objectives and you get a decent code that you can easily modify to serve your needs.

  4. Powershell is surprisingly good. It’s pretty close to a proper programming language while still being a convenient shell. It’s got object-based pipelines, types, functional constructs, etc. and it reimplements shell utilities to make use of those features. It might seem verbose at first, but there’s a systematic short alias naming convention. I’ve been using it on Linux for the past couple years and I no longer have to lookup weird bash syntax or quirks every time

  5. In shared environments, you script in what’s in every machine and others understand. In the past that used to be POSIX shells but now Bash is available everywhere. Then there’s the issue of which Bash version, but when you need the more advanced features it’s time to start considering something like Perl (fewer remaining users) or Python. And then, “traditional” distros tend to have Python 2 rather than Python 3 and depending on the org it can be a real pain to get 3 approved.

    Argh.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.