Bash-like scripting has become ubiquitous in operating systems, and it makes me wonder about its widespread adoption despite lacking certain programming conveniences found in other languages. While it may not be the ideal choice for large-scale software development, the bash shell possesses unique features that make it well-suited for interactive command-line processing, including pipelining, text manipulation, and file handling. Why isn’t there an alternative that combines the best of bash’s command-line capabilities with the robustness and scalability of traditional programming languages. Why do even new operating systems, such as Redox OS, opt for a similar syntax rather than a completely different programming language?

Here are some of the limitations I find in Bash compared to other programming languages:

  1. Syntax and Expressiveness:

    • Bash has a relatively simple syntax compared to other programming languages. It lacks some advanced language features such as object-oriented programming, complex data structures, and advanced control flow constructs.
    • The syntax of Bash can be less intuitive and more error-prone, especially for complex tasks or larger projects.
  2. Performance:

    • Bash scripts can be slower compared to compiled languages like C or Java. This is because Bash is an interpreted language, and each line of code is interpreted at runtime.
    • Bash may not be the best choice for computationally intensive tasks or applications that require high performance.
  3. Error Handling and Debugging:

    • Error handling and debugging in Bash can be challenging. Bash does not provide robust error handling mechanisms, and error messages can be cryptic and difficult to interpret.
    • Debugging Bash scripts can be cumbersome, as there is limited tooling and debugging support compared to other programming languages.
  4. Portability:

    • While Bash is available on most Unix-like systems, it may not be available on all platforms or versions. This can limit the portability of Bash scripts.
    • Bash scripts may not work as expected on non-Unix systems or require modifications to run on different platforms.
  5. Limited Standard Library:

    • Bash has a limited standard library compared to other programming languages. It lacks comprehensive libraries for tasks such as networking, database access, or advanced data manipulation.
    • Bash often relies on external tools or utilities to perform complex operations, which can introduce dependencies and compatibility issues.
  6. Lack of Modularity and Reusability:

    • Bash scripts can become monolithic and difficult to maintain as they grow in size. Bash does not provide strong mechanisms for modularization or code reuse.
    • Reusing code or creating libraries in Bash can be challenging, leading to code duplication and decreased maintainability.
  • corytheboyd@kbin.social
    link
    fedilink
    arrow-up
    31
    ·
    edit-2
    1 year ago

    It’s here, it’s there, it’s everywhere. The problem with replacing things that work with something “better” is that “better” is subjective, so you end up with a new “better” way every few years, and maintaining existing systems becomes a god awful slog. See the JavaScript ecosystem.

    The bash I wrote 10 years ago still works today, and it will still work in 10 more years. The same bash will very likely work on your computer, on a remote server, etc. This is the power of not chasing “better” all the time.

    Try running a Ruby or Node program from 10 years ago today on your computer. Now, try running it on a random Linux server.

    Please do not take this as a slight against Ruby or Node, or any other high level programming language. Bash compared to those is simply apples and oranges, they are not the same thing.

    By all means, if you have a project that requires a Ruby runtime anyway, write operational scripts with Ruby, run them with Rake, etc.

    Want a portable script that doesn’t depend on a complex runtime? Use bash.

    If bash is too limiting, use Perl. No, seriously. Perl is fine. It is about as ubiquitously available as bash, and the standard library likely has what you need to get the job done. People blindly dismiss Perl because some blog post told them to, usually in the context of writing application code. You’re not writing application code, you’re writing scripts. Would you write an application with bash? No.

  • 𝘋𝘪𝘳𝘬@lemmy.ml
    link
    fedilink
    arrow-up
    21
    arrow-down
    3
    ·
    1 year ago

    What features does bash have that make it so suitable for shells?

    You mean, except being automatically available in basically every Linux distribution without having to install any additional software?

    • HeavyRust@lemm.ee
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      They’re asking why it became available everywhere.

      Bash-like scripting has become ubiquitous in operating systems, and it makes me wonder about its widespread adoption despite lacking certain programming conveniences found in other languages.

      • ffhein@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        Because other languages available at that time lacked certain programming conveniences found in bash :) Despite its shortcomings, it’s still a very convenient language for running other programs, working with files, and piping output from one program to another, or to a file. Bash was first released in 1989, and I don’t know exactly when it passed the threshold for widespread adoption, but I can’t think of anything that would’ve been a better alternative.

        I think OP is also asking “why aren’t people switching to something else now” which is a completely different question.

      • 𝘋𝘪𝘳𝘬@lemmy.ml
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        1 year ago

        Because it’s automatically available in basically every Linux distribution without having to install any additional software.

          • maegul (he/they)@lemmy.ml
            link
            fedilink
            arrow-up
            4
            ·
            1 year ago

            yea … for me, until proven otherwise, I’m thinking bash + *nix shell ecosystem is basically a COBOL that isn’t cool to make fun of (yet?).

            All of the bash apologia I see whenever it comes up is not really encouraging. I get it, it’s got some handy features, but overall it’s clearly suboptimal for many, and that we keep on using because we’ve been keeping on using it but convince ourselves it’s good/cool … is not healthy.

          • 𝘋𝘪𝘳𝘬@lemmy.ml
            link
            fedilink
            arrow-up
            3
            arrow-down
            3
            ·
            1 year ago

            Because it was easily possible to become ubiquitous, because, well, what I said.

            There really is no other reason. Bash scripting is slow and lacks a lot of features. But it simply works.

      • stevecrox@kbin.social
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Engineering is tradeoffs.

        A command shell is focused on file operations and starting/stopping applications. So it makes it easy to do those things.

        You can use scripting languages (e.g. Node.js/Python) to do everything bash does but they are for general purpose computing and so what and how you perform a task becomes more complicated.

        This is why its important to know multiple languages, since each one will make specific tasks easier and a community forms around them as a result.

        If I want to mess with the file system/configuration I will use Bash, if I want to build a website I will use Typescript, if I want to train a machine learning model I will use Python, if I am data engineering I will use Java, etc .

      • hollyberries@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        I personally wouldn’t, because the Unix philosophy should still apply. If you need 50k lines of bash to do something that a collection of existing command line tools already can do, you may need to re-evaluate your needs.

        As @nous@programming.dev said here, POSIX compliance is extremely important. Much of the “real world” infrastructure is still UNIX based, especially in finance. It isn’t easy to replace those systems at all, especially a legacy codebase that literally the entire world runs on. COBOL and Fortran applications in banking are still being updated today, despite efforts to modernise systems because they just work and the code is pretty much hardened at this point.

        As always, in every industry, there is a “right tool” for the job. The great thing about the Unix philosophy is, if correctly applied across your stack, it doesn’t matter what language you write the tools in. Your bash script is only going to be forwarding that output to something that is suited to handle it. This person sped up their python application by using Rust for one set of functions.

  • matthewmercury@reddthat.com
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    Bash isn’t the only shell. Most systems can use zsh or fish or tcsh or whatever shell you prefer, if you like that better than bash. You’re gonna have to run a shell if you want to use the terminal, though, you understand that?

    Shell scripts are very good for specific tasks. Don’t use them for tasks that are unsuitable. Use python or go or node or c if those are better for your needs. Use the right tool for the job. But also, learn to understand why the industry has been using shell scripts for decades.

    • moon_matter@kbin.social
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      Bash isn’t the only shell. Most systems can use zsh or fish or tcsh or whatever shell you prefer, if you like that better than bash. You’re gonna have to run a shell if you want to use the terminal, though, you understand that?

      Defaults matter. There are a lot of situations where you aren’t allowed to install whatever you want. It would be less of an issue if other shells or language run-times came preinstalled. The problem isn’t really Bash itself. It’s the fact that it’s often the only dependable option. But thankfully that’s starting to change and you can usually find python preinstalled at minimum.

    • palordrolap@kbin.social
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      As a shell, tcsh was OK if only because it included GNU Readline (or something like it) and, despite being a couple of years younger, kind of beat bash to the punch for that user-friendliness on account of being a largely unchanged drop-in replacement for its predecessor.

      Unfortunately, that also means it’s as problematic as its predecessor too: Csh programming considered harmful.

      Not to be used for anything serious.

  • Crunkle_Foreskin@kbin.social
    link
    fedilink
    arrow-up
    8
    arrow-down
    2
    ·
    1 year ago

    I wouldn’t use the word “stuck”, Bash is a result of over 50 years of technological advancement and experience. It works on servers, remotely, is lean and powerful. It’s not that user friendly, because it doesn’t need to be.

    ZSH and Fish are available on *nix systems for a little bit more sugar. I personally don’t use raw Bash because I just love what ZSH can do, but I love writing Bash scripts.

    • GodOfThunder@lemm.eeOP
      link
      fedilink
      arrow-up
      22
      ·
      1 year ago

      This is so cool. It’s exactly what I had in mind when thinking of a modern bash alternative.

  • QuazarOmega@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    Everyone talks about the fact that Bash is what it is because it is first and foremost an interactive shell, but nowadays some design decisions are just inexcusable in my opinion, like the awful syntax of common programming constructs, the if in particular, that would only benefit from following how every other language works even if they aren’t meant as shells.
    Some also argue against the non-modularity with the fact that you should use it for only quick and easy stuff, but that’s just an excuse, if the language runtime that comes preinstalled in your system had modern features and sane syntax you would stick to that and save yourself from installing Python/Ruby if they’re not needed; and it is clear that there is a need for modularity, otherwise plugin managers wouldn’t exist, many swear by downloading the scripts directly and sourcing them in the name of “KISS”, but that is just silly when there is a good system set in place that makes it actually easier to manage it all.
    Then there’s the issue of the holy pipelining, that has more or less been overcome by some languages already, this example in Rust shows that it can be easy, so there’s no reason why a terse scripting language couldn’t achieve the same.

    In the end I don’t know what’s holding the landscape back, I noticed Xonsh that looks very interesting, but I never tried it, I wonder if it is POSIX compliant and if that aspect even is so fundamental to the success of a shell

  • eek2121@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    You aren’t. Even if you want to stick with bash, you can run scripts written in other languages. I have a few Ruby scripts. I can run them just like I do bash scripts.

  • Seperis@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Because for what it was made to do and what I want to use it for, it’s utterly ideal. It’s easy, it’s direct, it works seamlessly with any program’s command line, and I can run anything network-wide on any linux machine on my network out of box with no fiddling around. No check for version, no missing packages to hunt up, no libraries to download and verify; I type, I save, it runs, I’m done. If I need to integrate command line tools on six separate programs and/or five to eight scripts in two languages to do a stat/resource/network check on my Linux machines, I can do them all from one script and I can do it to six separate machines over ssh in a loop in under 200 lines of code and throw the results up on a webpage in apache with another thirty if I want to make it pretty in html. Then I set it to a cron job to run once an hour and forget it for months; it keeps on keeping on, I just check that webpage to see everything is fine, in separate tabs even. And I can do all that very very very fast and literally out of box; if I add a brand new machine, all I do is copy my base bash library over and set permissions and it’s ready to go.

    Those scripts will always work, on every linux machine, every time, in the same way; they will run in ubuntu, solus, fedora, arch, debian, raspberry pi, probably slackware I haven’t checked, the scripts do not care. Ones I wrote ten years ago are still running just fine.

    Bash is kind of like the general of my script and cli army; she does not need to know everything herself, she just needs to organize the troops to do their jobs, and tell me if someone’s slacking off because python decided to be a dick about a package or php is being cranky or apache just won’t speak to anyone no idea wtf is going on there or otbr vanished into the ether or all my wifi drivers are in revolt after an update. She does not stress me at all; she is the finder of my stresses before the drama hits critical, and this is why she is my favorite.

  • maegul (he/they)@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    How standard is Python on Unix machines nowadays? I’m guessing some relatively recent version of Python 2 is standard on many machines.

    Not sure how many would prefer it, but I’ve always wondered if retiring as a shell language would be a good home for Python. Not sure how well it’d work as a shell without some major changes, but it feels like something could have been done to get to a sweet spot and we could have slowly moved beyond bash to something nicer …?

  • nyan@lemmy.cafe
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Let’s see here. We’re talking about a thirty-plus-year-old language that was deliberately written as a superset of sh from 1979. Its main purpose is to glue together other command-line programs on 'NIXish systems to automate complex procedures for sysadmins. Using it as a general-purpose programming language, while not impossible, is kinda dumb if you have any other options. Within its original niche, it ain’t broke, so there’s no need to fix it.

    It’s a contemporary of Tcl and Perl, not of Python and Java (and sh is from the era where microcomputers mostly used BASIC dialects). Unlike Perl, it didn’t bolt on object orientation or other more modern features afterwards—and really, Perl was intended as just the kind of “shell script killer” you seem to be thinking of in your introduction. However, it never completely displaced the shell built-in scripting languages even in the days before it fell out of favour itself. Might be that there’s a reason for that.

  • bionicjoey@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Bash adheres to the POSIX standard for a shell, which limits what it can have in terms of UX. If you really want something with a different UX you can try something like fish. Just be warned that if you do, you’ll quickly learn how wrong your bullet point about bash not being portable is.