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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Bash is fine. Now powershell, that’s utter garbage.
50k lines is, IMHO, way too large for a bash script. I’d switch to python long before before that. Bash is primarily an *interactive shell. Bash has a lot of nice scripting capabilities (that few are aware of, let alone use) but its primary use is not as a programing language. As far as standard libraries go: sed, awk, grep, curl, netcat, etc… provide plenty of advanced capabilities. That’s the Unix philosophy, lots of small utilities that each do one thing well and that work with streams of bytes as i/o. Tie them together with a powerful shell, and an ordinary user can do quite a lot without “programming”. Is the Unix philosophy perfect? No. Has it proved to be the most flexible and successful compute environment developed for over 50 years? Yes.
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 .
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.
I upvoted because fuck microsoft but i was very surprised at how easy it was to script in ps. Outputs are formatted similarly and you can quite easily have exactly the info you want ,how you want, while in bash its a lot more loose. That comes with the open source territory though.
This, powershell is pretty nice albeit verbose and TTY in Windows suck and slow (haven’t scripted in PS since 4 years ago so not sure about current state of affairs). Python is my de-facto shell now if I want to do anything shell related.
Bah! I find it hard to believe that if you ever truly used ps that you’d think it was garbage.
I’m rather fond of it myself.
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?
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.
Because it’s automatically available in basically every Linux distribution without having to install any additional software.
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.
POSIX compliance for the most part. Which is meant to give you a consistent API you can write software against that will work on any UNIX system. At least that is the theory behind it. It basically acts as a lowest common denominator for UNIX systems. Want to write a script that will work on all systems - bash or a similar shell will almost certainly be present.
A new system can change this if they wanted to. But then they won’t be able to take advantage of all the existing bash scripts out there that everyone is writing. Which adds a lot of friction to adoption.
So in a way we are locked into a bash like shell now. Unless you can get a lot of distros to change this shell it is very hard to change it for a single one. And changing something so fundamental across lots of distros will upset a lot of people that are used to bash.
And shells overall are preferred to general purpose programming languages as their main focus is executing other commands and piping input/output from one to another or to/from files. Something most programming languages make a bit awkward as that is not their focus.
There are a bunch of non-POSIX shells, like fish, nushell, ion etc but these will likely not become the default anytime soon due to the inertia that bash has. But luckjly you can install what ever shell or language you want in addition to bash and switch to that for your interactive shell or even scripting if you want to. They just won’t become the defaults for a long time - if ever.
You’re missing the point.
Bash is the ducktape of programming languages.
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 …?
I’m guessing some relatively recent version of Python 2 is standard on many machines.
I hope not. Python2 has been EOL for a long time now and should not be used any more. And I really hate pythons dependency management.
Except this is about Bash … not bashing Python.
First, Python2 need not be EOL. I’m clearly talking about some parallel timeline where python as a *nix shell became a project and got traction. Somewhere around ~2000, when python2 was first released, some project works on making the necessary adaptations for a shell and presumably gets that working well.
Second, we’re talking about Bash and Bash scripts, any serious dependency management or package management doesn’t really factor into this, it seems you’re bashing Python as a fully fledged programming language.
The weakest point in my imaginary proposal, IMO, is getting python to work as a shell language. As a scripting language it’s fine and many are happy using it where Bash might be used. But as a shell, and in scripting too, it’s interop with core utils and commands is pretty suboptimal. Ergonomics would at some point require something to be done about that and I don’t know what a successful version of that would look like. If we’re talking about a POSIX standard, maybe all that’d be necessary would be a standard library that wraps everything needed? Or a nicer object/function/syntax for calling subprocesses, which various third party libs have tried obviously. The Xonsh project also comes to mind … a superset of python, which is a great idea IMO but maybe undermines the idea that python2 is everywhere already.
First, Python2 need not be EOL.
No. Python2 absolutely needs to be EOL. Let it die and be buried. Never to be resurrected again.
python2 was finally removed from Debian at the end of last year.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027108
It does not need to come back - and it especially does not need to become a shell built-in
python2 is everywhere already
That’s just not correct. It is not part of any modern distro by default. Even RH are planning on dropping it next year
I’m clearly talking about some parallel timeline
That is not clear at all from your first post. All you did was ask about the current state and postulate that python2 should be commonly installed nowadays. Then wonder if python could be made to act like a shell. None of that indicated you were thinking about some hypothetical parallel past timeline.
In our timeline python 2 is EOL and not installed by default on much if anything these days and should not be used by anything any more (despite some things still needing it - they really shouldn’t any more).
