People are generally bad about following their own advice. They're worst at following advice to avoid shell scripts. :-) We all know in theory we should move things to Python or another robust language once they become sufficiently complex, but in the moment, adding just this one feature takes precedence. Iterate "just one feature" a few times and you end up with a 1,000-line bash program. (The word "script" becomes inapplicable.) Now what? You want to add configuration support to your bash program? Well, you might as well use something robust to do it.

    import subprocess
    subprocess.run(["bash", "-c", """
    echo This is bash
    if hostname | grep box; then
       echo running on a box
    fi
    """], check=True)

    #!/usr/bin/env python3
    import sys
    import subprocess
    result = subprocess.run(["bash", "-c", """
    echo I am in bash, I have $# args, arg1 is "$1"
    set -x
    "$@"
    """, "dummy.sh"] + sys.argv[1:])
    sys.exit(result.returncode)

    subprocess.run(["bash", "-c", f"rsync {shlex.quote(filename)} somehost: | some-script"])

Have you seen the x-cmd package? It's nuts

https://x-cmd.com

It's legitimately impressive, the person/people behind this wrote some pretty interesting code, I've learned some things about Bash reading through parts of the code. But it's crazy at the same time.

Long before systemd took over the init world, Debian led a huge effort to switch their entire infrastructure to dash[1], specifically making heavy use of checkbashisms[2]. The main reason behind it was performance: POSIX sh implementations were much simpler, and easier to optimise.

[1]: http://gondor.apana.org.au/~herbert/dash/

[2]: https://linux.die.net/man/1/checkbashisms

My rule of thumb is that if a shell script calls for a Bash-only feature, exceeds 100 lines, defines more than three functions, includes a nested loop, or a pipeline that exceeds 80 characters, it's probably time to reach for Python.

There are reasonable cases for exceptions - my backup script has about 200 lines and 6 functions, but it's 100% portable between Linux & macOS.

> Using pip-installed libraries brings in the famous packaging problems, but you don't have to use it!

These days, with uv and PEP 723 inline script metadata, that's not an issue either.

    # /// script
    # dependencies = ["numpy"]
    # requires-python = ">=3.12"
    # ///
    import numpy as np

and

    uv run myscript.py

will just Do The Right Thing.

> And if your system has bash, it often has python as well, or at least it's easy to install.

The problem is, bash is a universal target. Every unixoid system has bash in one way or another, usually at /bin/bash or in a pinch /usr/bin/env bash. No matter if your target system is Debian oldoldstable or bleeding edge Gentoo, it will run.

Python however is a hot mess. Some operating systems are at `python` yielding v2, others v3. Others (Macports) have python2 and python3 binaries if the user doesn't also do a `port select` afterwards. The user may have overridden this with virtualenv's (that this exists at all is a disgrace in itself). And that all is before `pip` even has entered the stage, or before you try to figure out what whitespace format Python expects and what whitespace format you just used in the last YAML file you edited.

(The whitespace shit is what will keep me from using Python if at all possible.)

> rewrite it in a real language

This refrain shows up in every shell script discussion here, and hot take, I find it mostly ill-founded hogwash. Some of the worst spaghetti code I've seen is such Python and Javascript rewrites.

Choice of language only really helps when it encourages developers to use patterns that fit the underlying problem domain. However, Python's path of least resistance is OOP architecture, which usually fits terribly in the domains where shell scripts are ubiquitous, e.g. glue code between systems, infra administrative tasks, etc.

Almost all shell script tasks boil down to executing a linear collection of steps, and by organizing code thusly, I find shell scripts to keep code short, sweet, and very maintainable. Using a data-first design, with well-designed global state typically meshes well with shell's strengths—dynamic scope, pipes, word-splitting, etc, not to mention coreutils, grep, awk, etc.

IMHO, all the shell hate boils down to not recognizing an impedance mismatch between the programming paradigms of the programmer and language. Try writing Haskell like you would write Java or vice-vesa, and you'll end up with just as much of a mess.

</rant> This topic is a bug-bear of mine, for whatever reason. :shrug:

That's all well and good, but if you're looking for a language that will survive for decades, then BASH or shell scripts are a better choice. Often, there'll be some ancient machine that's been almost forgotten about and will die and need replacing. I can trivially copy a 30-year old BASH script and run it on a new machine, but can you do that with a 30-year old Python programme? How will today's Python survive the next 30 years?

I agree with you on that, but I had this task on a legacy project with over 50k lines of shell scripts, and out of nowhere, it needed to start reading INI files and loading those values into environment variables. That's why this was written!

> My rule has always been that once a shell script gets too complex, it's time to rewrite it in real language

Is Powershell a real language? Because it is a shell script too.

I think you meant to say "data types" and "data structures"?

I used to do the same but lately I've been enjoying writing scripts using bun.js and its shell API: https://bun.sh/docs/runtime/shell

The main reason is piping commands, way easier than python. It's very easy to convert a bash script to bun.

For ingestion, yes, but if you want to write back the ini, you have now lost all comments. Besides, jq's syntax is ... arcane.