4 ms·

Is there a reason bash is still the de facto shell scripting language other than sheer momentum of legacy? I'm able to get what I need done in it, but it's clun

Is there a reason bash is still the de facto shell scripting language other than sheer momentum of legacy? I'm able to get what I need done in it, but it's clunky and the syntax is horrid. I guess it forces you to move to a proper language once scripts grow to a certain size/complexity, so perhaps it's by design?

awesomeMilou 3y ago
Are you sure it's bash? Most scripts on FreeBSD's are written for sh, which I feel is much more widely supported due to being part of the POSIX standard. Bash is just popular I think.
- HankB99 3y ago
  Bash is pretty much expected to be installed on any Linux distro. On FreeBSD (and likely other BSDs) it is an optional install. If you want a script to run on either, use sh. If strictly Linux, bash is probably safe. Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together. Some times it is surprising what can be accomplished. I wrote a program to import pictures from an SD card on Windows using C#, copying pictures to C:\Pictures\YYYY\MM\DD according to the EXIF data or failing that, file time stamp. I tried to port it to Linux but ran into problems trying to connect to the EXIF library. After struggling with that, I rewrote it using sh, some EXIF tool and various file utilities. It took 31 lines, about half of which were actual commands and the rest comments or white space. A much bigger project is a script to install Debian with root on ZFS. It's mostly a series of CLI commands with some variable substitution and conditionals depending on stuff like encrypted or not.
  - xk_id 3y ago
    > Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together. Once I’ve learned bash, I realised how much more problems i could solve, in addition to a majority of old ones. It’s an entirely new level of “computer literacy”; and a more genuine one.
- xp84 3y ago
  I suppose it’s an ambiguous designation. I feel like when I see a shell script in my work, which is not in operating systems development of course, people are targeting bash. I agree many things are careful to target sh for certain reasons (e.g. a script that runs in a container where the base image doesn’t have bash installed) but i still think GP’s question is interesting because it’s not common to see, say, a zsh shell script, but seeing #!/bin/bash is super common.
  - ykonstant 3y ago
    I have done some delightful stuff in `zsh`, but I always lament how slow its numerical array traversal is. Frustratingly, experts told me it really doesn't have to be slow, the devs just don't seem to be bothering to revamp the underlying data structure because they are focusing more on associative arrays.
  - chasil 3y ago
    If you are on Ubuntu, and you must target #!/bin/sh then bash is not an option. Android and Apple are in similar situations.
- joveian 3y ago
  FreeBSD's /bin/sh is based on ash, like NetBSD's, although I'm not sure how much they have in common these days. dash was forked from NetBSD's version of ash and then simplified considerably and fixed up to be fully (? or at least mostly) POSIX compliant. A while after that NetBSD's shell also had a bunch of POSIX fixes. I'm not sure how FreeBSD's shell is in terms of strict POSIX compliance. In my opinion, bash has two things (at least vs NetBSD's shell, possibly a few more vs POSIX) that make the average shell script (that I write) much easier. The first is &> which makes it easy to redirect both stdout and stderr to a file for logging. The standard 2>&1 can work but needs to be placed correctly or it doesn't work. That place isn't always the obvious place like it is with &> and running bash seems much preferrable to me than figuring that one out. The second is ${var@Q} which prints var quoted for the shell, which is nice to use all over the place to make sure any printed file names can be copied and pasted. My sense is that targeting POSIX is usually done for maximum portability or for use on systems that don't have bash installed by default. However, bash is quite widely available even if not by default and very widely used so I wouldn't say it is unreasonable to look at bash as the de facto standard and POSIX and other shells as being used in more limited circumstances.
hyperadvanced 3y ago
It really is just legacy and momentum. Recent additions build on sh/bash really well but in the end shell scripting is a means to an end that need to evolve much slower than standard programming languages. I think bash/sh’s key feature is that they are anti-entropy, there’s no development or evolution so there’s no chance you need to mess with dependencies or new features, the stuff that worked 20 years ago will continue to be the “bread and butter”. By design, this results in a system that’s averse to change and incentivizes people to reach outside of its limits when they are met.
theonemind 3y ago
bourne shell scripting is good enough, which makes it nearly impossible to replace. Plan9's rc is a bit cleaner, and no one is going to switch for 'more of the same, but cleaner'. You haven't switched to something similar but better even though you could literally do it right now https://pkgsrc.se/shells https://pkgsrc.se/shells , and it doesn't run any different for anyone else. It usually takes something several times better in some crucial aspect to replace an entrenched technology. For example, Plan 9 is better than UNIX-like systems, but not good enough to replace them. I don't think it's possible to make something good enough to replace bourne shell scripting in its niche because before you have something several times better, good enough to actually replace it, you're in a different ecological niche or problem domain, for real scripting languages like Perl, Python, and Ruby. It's a local maximum solution that sucks the air out of the room for potential competition closer to the theoretical global maximum solution for the narrow problem domain.
AtlasBarfed 3y ago
It's ubiquitous. But bash is so bad I wrote a ton of namespace shortened utils for using groovy scripts. Sooooooooooooooooo much better. use IDEs for dev, save library system, groovy smoothed almost all Java annoyances
ndsipa_pomu 3y ago
Its legacy usage is certainly a big part of its popularity. You can generally rely on having a newish version of it on any modern distro and you don't have to worry about the version unless you want to do stuff with arrays etc. What I find compelling about bash is its position in relation to other languages and tools. It's ideal for tying together other tools and is close enough to the operating system to make that easy whilst also not requiring libraries to also be installed (c.f. python). I often hear the opinion that more complex scripting should be moved to a language such as python, but that adds a layer of complexity that is probably not helpful in the long-run. I can take a bash script that I wrote twenty years ago and it'll still work fine, but a python programme from twenty years ago may well have issues with versions.
bregma 3y ago
Perfection is the enemy of Good Enough.

awesomeMilou 3y ago

Are you sure it's bash? Most scripts on FreeBSD's are written for sh, which I feel is much more widely supported due to being part of the POSIX standard. Bash is just popular I think.

HankB99 3y ago
Bash is pretty much expected to be installed on any Linux distro. On FreeBSD (and likely other BSDs) it is an optional install. If you want a script to run on either, use sh. If strictly Linux, bash is probably safe. Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together. Some times it is surprising what can be accomplished. I wrote a program to import pictures from an SD card on Windows using C#, copying pictures to C:\Pictures\YYYY\MM\DD according to the EXIF data or failing that, file time stamp. I tried to port it to Linux but ran into problems trying to connect to the EXIF library. After struggling with that, I rewrote it using sh, some EXIF tool and various file utilities. It took 31 lines, about half of which were actual commands and the rest comments or white space. A much bigger project is a script to install Debian with root on ZFS. It's mostly a series of CLI commands with some variable substitution and conditionals depending on stuff like encrypted or not.
- xk_id 3y ago
  > Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together. Once I’ve learned bash, I realised how much more problems i could solve, in addition to a majority of old ones. It’s an entirely new level of “computer literacy”; and a more genuine one.
xp84 3y ago
I suppose it’s an ambiguous designation. I feel like when I see a shell script in my work, which is not in operating systems development of course, people are targeting bash. I agree many things are careful to target sh for certain reasons (e.g. a script that runs in a container where the base image doesn’t have bash installed) but i still think GP’s question is interesting because it’s not common to see, say, a zsh shell script, but seeing #!/bin/bash is super common.
- ykonstant 3y ago
  I have done some delightful stuff in `zsh`, but I always lament how slow its numerical array traversal is. Frustratingly, experts told me it really doesn't have to be slow, the devs just don't seem to be bothering to revamp the underlying data structure because they are focusing more on associative arrays.
- chasil 3y ago
  If you are on Ubuntu, and you must target #!/bin/sh then bash is not an option. Android and Apple are in similar situations.
joveian 3y ago
FreeBSD's /bin/sh is based on ash, like NetBSD's, although I'm not sure how much they have in common these days. dash was forked from NetBSD's version of ash and then simplified considerably and fixed up to be fully (? or at least mostly) POSIX compliant. A while after that NetBSD's shell also had a bunch of POSIX fixes. I'm not sure how FreeBSD's shell is in terms of strict POSIX compliance. In my opinion, bash has two things (at least vs NetBSD's shell, possibly a few more vs POSIX) that make the average shell script (that I write) much easier. The first is &> which makes it easy to redirect both stdout and stderr to a file for logging. The standard 2>&1 can work but needs to be placed correctly or it doesn't work. That place isn't always the obvious place like it is with &> and running bash seems much preferrable to me than figuring that one out. The second is ${var@Q} which prints var quoted for the shell, which is nice to use all over the place to make sure any printed file names can be copied and pasted. My sense is that targeting POSIX is usually done for maximum portability or for use on systems that don't have bash installed by default. However, bash is quite widely available even if not by default and very widely used so I wouldn't say it is unreasonable to look at bash as the de facto standard and POSIX and other shells as being used in more limited circumstances.

hyperadvanced 3y ago

It really is just legacy and momentum. Recent additions build on sh/bash really well but in the end shell scripting is a means to an end that need to evolve much slower than standard programming languages. I think bash/sh’s key feature is that they are anti-entropy, there’s no development or evolution so there’s no chance you need to mess with dependencies or new features, the stuff that worked 20 years ago will continue to be the “bread and butter”. By design, this results in a system that’s averse to change and incentivizes people to reach outside of its limits when they are met.

theonemind 3y ago

bourne shell scripting is good enough, which makes it nearly impossible to replace. Plan9's rc is a bit cleaner, and no one is going to switch for 'more of the same, but cleaner'. You haven't switched to something similar but better even though you could literally do it right now https://pkgsrc.se/shells https://pkgsrc.se/shells , and it doesn't run any different for anyone else. It usually takes something several times better in some crucial aspect to replace an entrenched technology. For example, Plan 9 is better than UNIX-like systems, but not good enough to replace them. I don't think it's possible to make something good enough to replace bourne shell scripting in its niche because before you have something several times better, good enough to actually replace it, you're in a different ecological niche or problem domain, for real scripting languages like Perl, Python, and Ruby. It's a local maximum solution that sucks the air out of the room for potential competition closer to the theoretical global maximum solution for the narrow problem domain.

AtlasBarfed 3y ago

It's ubiquitous. But bash is so bad I wrote a ton of namespace shortened utils for using groovy scripts. Sooooooooooooooooo much better. use IDEs for dev, save library system, groovy smoothed almost all Java annoyances

ndsipa_pomu 3y ago

Its legacy usage is certainly a big part of its popularity. You can generally rely on having a newish version of it on any modern distro and you don't have to worry about the version unless you want to do stuff with arrays etc. What I find compelling about bash is its position in relation to other languages and tools. It's ideal for tying together other tools and is close enough to the operating system to make that easy whilst also not requiring libraries to also be installed (c.f. python). I often hear the opinion that more complex scripting should be moved to a language such as python, but that adds a layer of complexity that is probably not helpful in the long-run. I can take a bash script that I wrote twenty years ago and it'll still work fine, but a python programme from twenty years ago may well have issues with versions.

bregma 3y ago

Perfection is the enemy of Good Enough.