Why aren’t new terminals that use another language? It seems so antiquated getting errors for not writing the functions in the correct order among other things.

  • eyeballkid@lemmy.ml
    4·
    3 years ago

    Shell scripts usually expect something POSIX-compatible, but you don’t have to stick with the default for user-facing tasks. Fish, zsh, powershell, and a whole bunch of niche shells are available to try. Anyhow, in the broad context of Unix default installations bash has a lot of competition.

    On several unix-like Oses more than one shell is used depending on context. A great interactive shell with loads of features may be overkill if you just want to execute a script. Some OSes don’t use bash at all.

    FreeBSD uses tcsh as its default root shell, but it uses ash shell (sh, it started as a clone of Bourne shell) for users and as the interpreter for system commands. This combo confused me at first and led me down a shell research rabbit-hole. ash is a stripped down shell that aims to be small, fast, and largely POSIX-compliant.

    In Ubuntu, bash is the default shell for interactive terminals, but dash is used to execute scripts by default. I think that dash started as a debian port of the ash shell.

    MacOS and Kali both use zsh as the default shell. I don’t know what they use by default to run scripts, but I would guess that it isn’t bash.

    Also, something that took me a while to figure out is that Bourne-Again Shell (bash) is not the same as Bourne Shell (sh). Further, sh does not always denote Bourne shell, but could be ash or dash or something else.

  • Aarkon@feddit.de
    3·
    3 years ago

    I‘d say one of the primary reasons is compatibility. There is a lot of software for the Unix world that expects some kind of environment that behaves similarly to bash - imagine for instance of the bazillion of startup scripts that exist around certain tools. You’d have to be 100% backwards compatible with the bash language if you were to invent something to replace it, otherwise all those things wouldn’t work in your shell.

      • vi21@lemmy.ml
        0·
        3 years ago

        Because people code in Bash. For example, a Makefile that I downloaded from GitHub didn’t work on my computer, since my computer’s default shell was Dash.

        The Makefile didn’t have the shebang to tell which shell is required, but it looks like a Bash script and it works on Bash.

        • Amicese@lemmy.ml
          1·
          3 years ago

          The Makefile didn’t have the shebang to tell which shell is required, but it looks like a Bash script and it works on Bash.

          I think the fault is in the makefike, not that bash is commonly used.

          I use bash for interactive sessions and POSIX shell for scripts (including the shebang).

  • Aiwendil@lemmy.ml
    2·
    3 years ago

    I guess a mixture of POSIX compatibility, backward compatibility and non-interactive shell use-cases.

    Being somewhat POSIX compatible offers a way to write scripts that work on many systems independent of the actual shell implementation (bash, dash, zsh…). But this means major overhauls of the shell “language” are out of question…

    Backward compatibility gets important for things that ignored the first point and used features only available in bash. Given that bash is the default for 30 years for linux now there are probably plenty of examples.

    And while bash is not the smallest shell it is also not the largest one…and rather configurable at compile-time when it comes to supported features. This makes it a viable option as “shell-script” interpreter for systems that hardly have any interactive shell usage. It’s not a completely bare-bone shell so you get a bit of “comfort” for scripts but you can remove unnecessary things like interactive command line editing with lib readline…I can imagine some embedded systems find uses for such a shell.

    And it’s not that there aren’t alternatives…Microsoft’s Powershell is probably the most successful one “recently”. But changing all existing “workflows” from a text-based one to an object based one is not a trivial task…and in addition you run in new problems with any new shell design (For example I really dislike the overly verbose interactive use age of powershell but that’s rather subjective)

  • coleman@lemmy.ml
    2·
    3 years ago

    The other answers are great. But consider the following, as well.

    All the mainstream package managers rely on POSIX-ish shell interpreters. Arch Linux PKGBUILD files require bash syntax, specifically.

    RPM and .deb package formats literally embed shell scripts to perform pre- and post-installation tasks. They treat these scripts like hooks.

    For instance, a common task would be to create requires users and directories for a program. Quite literally something like mkdir -p /var/lib/myprogram.