Because cross-OS (not just cross-linux-distro but even that) standards-making doesn't exist anymore in a real non-broken way, and we're stuck with whatever standards of 20+ years ago. Whether official or de facto (technically bash is just de facto although `bash --posix` or `sh` is an official real standard). There basically isn't any "innovation" happening in this space in a way that could really result in anything as pervasive as bash. Maybe also cause it's just not "interesting" anymore, the 'sexy' things are many levels of abstraction higher than they were when bash came to dominance. It feels like now we're just stuck with it forever, indeed.

Maybe it's time for some other body --- say, freedesktop.org --- to start standardizing things that have traditionally been in the domain of POSIX.

After all, HTML got much better when WHATWG took W3C's toys away and actually started innovating HTML again. Maybe it's time to do something similar with Unix: I'm sick and tired of people telling everyone that we have to stay in some 1995 time capsule because we need to follow The Standard and if The Standard hasn't changed, too bad.

You say "don't exist anymore" but when was it better? Pre-Mac-OS-X you didn't even have an easy to access shell there on Macs, and Windows wasn't bash either. So if there was a golden era for that, it never included the two predominant desktop OSes.

De-facto standardization has at least brought us free officially-supported options for running Bash or other *nix shells on both of those platforms(if terribly outdated on Mac).

I agree with your broader point that we seem stuck with old shells and no contenders seems in a position to replace them. However some are certainly trying, like osh [1] that takes backwards compatibility with bash seriously, which makes adoption easier.

Maybe it'll be like the C++ vs Rust situation?

https://www.oilshell.org/

My feeling is that it is about convenience when typing at the terminal. Having a unified language for both scripting and entering commands is quite convenient. Also, bare strings while typing at the terminal is very convenient! It would be really annoying if we always had to add quotes for string args when we're typing at the terminal:

  $ cat "file.txt"

...and I don't even know what options would look like... maybe:

  $ ls "*.txt", ["l", "a"]

I dunno... this would mean we'd probably need parens now for precedent-type concerns:

  $ ls("*.txt", ["l", "a"]) > "file.txt"

Anyway, that is why I understood that it's this way. I can't point to a resource about it, though.

You look like you are just about to discover Powershell.

Powershell is how I instrument cross platform CI scripting, with the power of the module concept and manifess now you can write real powerful type safe apis that can run anywhere. It has its quirks though...

Any gotchas with running the same scripts on Windows and Linux? I've been thinking about switching to PowerShell. Love it on Windows. Never tried it on Linux but I did try it on macOS a few years ago and remember some quirks. Currently a bash (over)user.

One gotcha is powershell core has some different apis then the 'windows powershell', best to deploy core on both systems to unify the api.

Also powershell has no support for automatically handling external shell commands that error, you must manually check $LASTEXITCODE (easily done with a custom invoke api that you use for everything).

Also well, some of the escaping in strings is really odd...

You have to add quotes in bash if the filename contains a space. Variables should also be quoted for the same reason, because their values might contain spaces. "${var}"

Only in a script. On the command line, tab expansion will escape any special characters in a filename.

don't forget to handle filenames with newlines in them as well!

> It would be really annoying if we always had to add quotes for string args when we're typing at the terminal

With bash (and I suspect with every other popular shells out there), it actually means something different. In your second example, if you don't use quotes, the shell will do the extensions, but if you do, the process will have to do it (and in the case of ls, it cannot).

In some case it's good to have the shell taking care of it, but sometimes (eg, when using 'find') it's not.

My examples are a made-up idea of what a “real” programming language would look like in a shell, not actual bash.

Sorry, clearly my comment wasn't very helpful.

I was trying to point out that quoting parameters or not could bring a different meaning for a shell (as one could see it with Bash), with the implied consequence that one would have to carry over that nuance somehow to a shell where all parameters would have to be quoted.

I feel like this comment is almost a kind of inverse of https://news.ycombinator.com/item?id=23424853 (which I remember to have found interesting).

ruby in some cases feel just like shell scripting, even more than perl.. you can even do piping to chain two commands together https://stackoverflow.com/questions/4234119/ruby-pipes-how-d... (edit: using the shell library https://github.com/ruby/shell so, not out of box in ruby, unfortunately, which is a mortal sin for replacing bash in scripts =/)

Here are the ways to run a program in ruby https://stackoverflow.com/questions/7212573/when-to-use-each...

Stephen Bourne was a great fan of ALGOL, and had C preprocessor directives to "ALGOLify" C.

https://research.swtch.com/shmacro

The Bourne shell thus adopted ALGOL syntax, distinct from anything else in UNIX.

David Korn brought a pile of C, and wedged it into a max 64k program space (for Xenix), and his upward-compatible Korn shell (ksh88) had many, many features.

Then there were the "UNIX Wars"...

https://en.wikipedia.org/wiki/Unix_wars

The fallout of this was the choice of a few Korn features, but not all (no arrays, coprocesses, [some] eval, regex, et al.)

The wars defined the POSIX shell. Yes, it can be infuriating.

It's because Bash is everywhere and is thus the next least common denominator after sh.

Bash is not everywhere.

There are two very distinct places where Bash is not, that I have found.

Bash is not in busybox. It pretends to be, but what is really there is the Almquist shell, with a bit of syntactic sugar to silence the common complaints.

Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms.

It is important to know the POSIX shell for these reasons.

Bash is readily available everywhere, though. Is there a widely used OS that cannot run bash, but can run BusyBox ash or dash?

Bash is not used in Android.

The Android userland explicitly avoids any GPL software.

The Android system shell is the MirBSD Kornshell (mksh).

This is (obviously) a massive platform.

But, you can nevertheless install bash on Android. That was my ask -- show me a widely-used OS that cannot run bash but can run other similar shells.

> Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms.

When writing a bash script, shouldn't you be setting the shebang to /bin/bash which is available on Debian?

Bash is the default interactive shell, but the Almquist shell is the default for /bin/sh, and must be used for all system startup activity.

It is otherwise advisable when speed or portability are required.

If you want to choose a programming language, there are hundreds to choose from. You could write a small program ("script") in Brainfuck. But that would be really annoying, and it would take you a long time to get anything done. Other languages may also take a long time to write, test, execute, and maintain. And they may be better at some things than others.

You have to step back and remember the point of all this. Why are you programming? To solve a problem, and make a human's life easier. What is the problem you are trying to solve? How can we make the human's life easier? In this case, it's "I want to combine bunch of programs together in a command-line interface, to make it easier to use these programs to get my work done on the command-line." So, what solution should we choose for this scenario?

Lots of different "scripting" languages exist (we used to call them "glue languages"). Today Python is the most popular, and before it was PHP and Perl. But who cares if they're popular? What are they good for? Why would you choose one over the other?

Python is a general purpose language which is easy to learn, easy to write, and easy to read. Well that sounds nice, but it's very "general" and not specific to our use case. PHP is a language designed for use in web development. Perl is a language designed for system administration-type tasks.

Bash scripting is designed for making it easy to combine already-existing programs in a command-line shell, with no modification or creation of programs required. The only "dependency" is the Bash interpreter (which happens to also be the command-line interface we started our problem with! how convenient!) and an existing collection of software tools that work with each other through a command-line interface. Every part of it is explicitly not designed to "make programming easier". Instead, it is designed to make "combining programs in the command-line" easier. The result is things like every single word you type is potentially just an outside program being executed, or arguments to that program. No other language has this quirky behavior, because they're not designed solely to make command-lines easier to use.

I know Perl well, and the language is fantastically useful as a system scripting language. It combines some of the best features of common shell scripting programs with more programming language-specific features. It is designed with shortcuts and "magic" to make quick work of command-line scripting tasks. But ultimately Perl was not built into the command-line, so its utility is always a bit stilted. Going between the shell and the Perl code and back to the shell isn't as flexible as if the Perl code was embedded in the command-line. Perl also doesn't have as simple a facility for pipes as a command-line shell does. Oh, and a Perl install is rather large, isn't available everywhere by default (anymore), and has all the usual dependency problems. So even though I know Perl very well, if I need to just combine existing programs in the command-line, I always use Shell scripting instead of Perl. (There are Perl shells which solve this problem, but then everyone needs to learn Perl, and Perl can be.... idiosyncratic)

You could also use Awk for a large number of general programming tasks, but again it's designed for a different specific problem: pattern-scanning and processing, not generally combining programs together.

So we use shell scripting to solve the problem because it was designed specifically for our problem, it's ubiquitous, and simple to use. You could use any other programming language, but it wouldn't fit our scenario as well. Once your use case changes, and you are no longer only trying to combine existing programs together, or the existing programs don't do what you want them to do, then you need to use a different language that better fits that new use case.

> Is there a reason we aren’t using a shell with a proper programming language for scripting?

Mostly because the people who want to introduce a "programming language" into the shell don't prioritize being a shell.

Check out the "Oh" shell for contrast. This is what a programming language looks like when you force it to conform to being a shell first priority.

https://github.com/michaelmacinnis/oh

https://www.youtube.com/watch?v=v1m-WEZz46U

This is "Scheme-like" (actually the late John Shutt's Kernel-like) but has FEXPRs so things can be redefined and evaluation can be controlled.

Perl used to be used a lot to automate things. I feel Python has taken some of that, but also have seen Bash being picked up more.

I tend to start writing things in bash (piping into things like grep, tac, sed, etc

However if I’m not careful they get painfully complex and I tend to regret not writing it in perk. As such I now switch to using Perl when I get to the function stage, or anything other than the most simple bash arithmetic.

I don't know why "we" are. Just use Python. Or whatever language you're using for your main system (I've written "scripts" in Scala, sure it takes a second or two to warm up the JVM but it's honestly fine). Or TCL if you really must have a language that can be used as a login shell.

shell is good enough, when people started to use script language, they just wanted to fill the empty between bash and C, no one want to replace it, so bash and other shell still there

There's csh.

In about 1995 I asked the question "how can a shell intended for C programmers not support functions?"

I've still not found a suitable answer.