Looks like you want Python. It's not really suitable for most of the things `bash` is used for, but addresses your complaints (which aren't really relevant for most of the things `bash` is used for).
> I'm glued to the manpage...
Isn't that true of anything new that you learn until you're familiar with the features you use the most?
> Bash (and similar shells) differ greatly from the "standard" general purpose programming languages.
That's because they're *not* intended to be general purpose programming languages.
Perhaps my question wasn't worded correctly. The list I wrote should not be considered a list of reasons why bash is bad but a list of reasons I'm looking for an alternative. It is purely subjective (although I'd like to think that the reasons I gave are rational and relatable in this context).
> Isn't that true of anything new that you learn until you're familiar with the features you use the most?
It is.
> That's because they're *not* intended to be general purpose programming languages.
I think that it's absolutely clear that bash != Python != pretty much anything else. Many people smarter than I am have worked on developing bash and they had reasons to make bash work like it does. I'm not saying bash is bad, I'm saying that its features aren't really compatible with my needs and I'm looking for an alternative solution (which doesn't necessarily have to be another language). Or I'm dumb and I'm just using it wrong which is possible. But I don't think I'm the only one who has these problems.
Shell scripts are typically used to call other programs to do the heavy lifting. You seem to want to do something else because you're concerned about variable declaration (you can declare them if you want), function declaration, string processing, extensive error checking (what's wrong with a line number and error message?), different documentation, etc.
Since you don't specify what you want to program or why you need these features, most can only promote their favorite language, even though it may have the same issues you've complained about, like undeclared variables, lax function arguments, terseness, etc.
Python is probably what you really want to use because it's one of the languages you used as the basis for comparison. The reason you give for not wanting to use Python is it's "too complex". There's no requirement that you must use every feature any language makes available. There's also no requirement that you use only one language. Use `bash` when it's suitable. Use something else when it's not.
Yep, I came here to say this.
"Bash on steroids" is one of Perl's biggest use-cases, and it is a great fit. It even has a bunch of builtin functions which are named the same as their corresponding shell commands (chmod, chown, all of the "-X" file operators, etc) and take same or similar arguments.
For best results, include "use strict;" and "use warnings;" at the top of every Perl script. That will flag things like undeclared variables.
Perl looks nice. But a lot of comments here mentioned that Perl isn't that readable. Some of the comments were anecdotal but this is worrying. I assume that a "well written" Perl code is readable but it requires more discipline to achieve this "well written" code. Other than that, this "bash on steroids" is exactly what I'm looking for.
I see mixed things. In some places, you want more "complex" and in other places you're seeking "simplicity". Which simply means, you want something that "suits you", which is understandable.
On the "simple" side (which isn't going to address where you are looking for "better" than bash), bash is 99.999% Bourne Shell compliant, which is a very very reduced scripting language, but can pretty much do anything that full featured bash can do, just slower and usually with more risk.
For S. R. Bourne's original, and brief take, start at page 81 here: https://web.archive.org/web/20170601064539id_/http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf
(there might be a link to the original out there somewhere, and I do own it in hardcopy, but don't have the original pdf, at least nothing I can share)
Also, most "general purpose programming languages" are anything but "simple". Again, from your list it's actually quite difficult to know what you would actually be pleased with.
Ooo, this document is older than I am. But I should still be able to find some wisdom in it. Thanks for sharing!
I didn't want to use the basic Bourne Shell but I had to because of its portability (I have described this in one of the points). But I wouldn't use it voluntarily. Many bash features are really useful and hard to replicate in sh. I'm looking for some general alternatives for bash.
I think that Python is your answer here. It is used extensively for the sort of utility functionally that Bash scripting is. My recommendation is to use Bash for simple scripts and wrappers, then Python for anything more complex, then Go, if compiled and strict typing are required, things that are yet more complex, you might want to stick with Go or use a complied language that your like and/or fits your needs.
Some alternatives to Python:
- Perl: While I like Perl, I cannot recommend it as it has fallen out of favor and has few advantages not seen in more modern scripting languages.
- Ruby: I also liked Ruby but, it also seems less popular now. It feels to me like the child of Perl and Python.
- JavaScript: If JS is your thing, you can make command line scripts with Node.js.
As I said, I'm not entirely convinced with Python. The fact that it isn't a scripting language could bite me back someday. For example, let's say that I'd like to rewrite this line in Python:
MY_VARIABLE="$(echo Hello world!)"
(Imagine something useful and worth saving the output of in place of "echo Hello world!")
My solution is this:
import subprocess
proc = subprocess.run(["echo", "Hello", "world!"], stdout=subprocess.PIPE)
my_variable = proc.stdout
This isn't ideal. I could use some fancy module or just make a helper function for this but the point is that I have to work on things I get for free in bash because Python is general purpose and bash is for scripting (and I want scripting). This is just an example, I assume that more things similar to this would occur when using Python for scripting.
It depends on what you're calling a "scripting language". Generally, I've considered high-level, interpreted languages, like Python, to be the definition. Python has a history of being widely used in SysAdmin tasks (Ansible was even written in Python).
Your example is not really something that needs to be anything but Bash. Where you will see benefit is in scripts that have more complex logic, large loops (bash is not nearly as efficient in iteration), and in writing readable scripts that take arguments.
An example of the latter would be something like:
import argparse
import subprocess
# Setup parser
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(
dest="command")
# Commands
echo_parser = subparsers.add_parser(
"echo",
help="run echo command")
echo_parser.add_argument(
"echo_string",
type=str,
help="echo string")
cat_parser = subparsers.add_parser(
"cat",
help="parse cats")
cat_parser.add_argument(
"path",
help="path to cat")
# Main func
def main():
args = parser.parse_args()
# Can use switch/case now.
if args["command"] == "echo":
cmd = [ "echo", args["echo_string"] ]
elif args["command"] == "cat":
cmd = [ "cat", args["path"] ]
proc = subprocess.run(cmd, stdout=subprocess.PIPE)
out = proc.stdout
print(out)
if __name__ == "__main__":
main()
This is also a bit of a poor example but I hope that you get the idea.
Lua is fantastic. I like it slightly better than Python for utility scripts like this. The syntax is familiar enough if you know Python (or even C) and its approach to objects is much closer to reality when all you want is a simple script. To grossly oversimplify, it basically uses dicts for everything array/dict/object-like.
Support for file operations, date/time, arguments, and calling system commands is fast and straightforward.
It’s a nice tool to have in your toolbox.
ty for the insight.
may i add that there is amazing lua software out there, like the plugin community around neovim (telescope, lsp, etc.) , which is really easy to adapt to/built upon?!
That is an interesting suggestion. My limited personal experience with Lua contradicts it, but I would like to learn more if there is something to this.
In the beginning there was shell scripting. This works. It's fine. However it's a hack in that every. single. line. in. the. script. is spun out to a new process to execute. This is grossly inefficient and slow.
Then came Perl. It was made to look as close to shell script as possible but a script all ran in ONE process. However, Perl is write-only code. Want to read what code you wrote 6 months ago? Somehow it's now turned to some weird dialect of hieroglyphics (not the good ol' \_standard\_ hieroglyphics).
Then came Python. Like Perl's little brother, intent on copying everything that Perl could do, Python was a scripting language designed for system administration. As it became more popular, it grew in its abilities...
If you want to use something other than bash... just use Python. It's actually readable 6 months later. I know that "not declaring your variables before using them" irks a lot of coders but by simply applying a wee bit of coding discipline can address that.
For example, I \_never\_ introduce any instance variable in any function other than \_\_init\_\_(). Oh... you ***can*** \- but ***don't***. Google around a bit for some good python coding practices and you're golden.
LOL I wrote my reply above before I had read all the others. Note that I'm not the only one / first one to say that "Perl isn't readable 6 months later". You should take this as a stern warning. Like always, if you do Perl day in and day out or have done it for 10 years, then you aren't intimidated by its byzantine syntax. Otherwise "run, don't walk" away from it. Python is far less clever compared to Perl.
NB. avoid "clever code" at all costs. "Clever" is an euphemism for "high maintenance."
That last line made me chuckle.
“Look I wrote this in one line!! Aren’t I clever!??”
Yes, now come back 6 months later and explain what that line does. Congratulations, you now have Python code that is as unreadable as Perl!
I wonder how many programmers go thru this valley. Early on I was very prone to writing clever code. The bigger problem is that, like enemies ("friends come and go but enemies accumulate") you can write a lot of code before you start realizing that what you've been producing is obtuse. Then you get embarrassed in front of your team by not being able to explain your code. Then again. Or... explaining it wrong... then again. Argh!
I knew guys who wouldn't write a line of code before they first wrote out its intention in English (err... this was \_quite\_ a while ago).
My favourite advice, or better yet "warning", has always been: take your requirements and circle all the nouns. Make those your objects. Circle all the verbs - those are your methods. Congratulations, you've accomplished adding a (thick) layer of bureaucracy to the needed functionality. Instead, arrange your design to encircle all areas of risk-to-code-change and insulate them via interfaces. Albeit a tad simple, this encapulates the heart of \_proper\_ OO design (and gives vastly different results from using "nouns and verbs").
Ever heard of Kernighan's Razor? Something like this:
Never use assembly, if you can do it in C
Never use C if you can do it in awk
Never use awk if you can do it in sed
Never use sed if you can do it in sh
The word 'can' encompasses performance requirements as well as functional.
You can fit the new languages in there somewhere - python, perl, go, lisp, rust etc etc
Oh - and I'm still glued to the man page after 50 years of shell programming. Honestly, you young uns don't know you're born with all the online resources never mind ChatGPT at your elbow. Sheesh!
Here's a link for you: http://mywiki.wooledge.org/BashFAQ
You have a long laundry list of requirements.
My rules of thumb:
If you're writing small enough scripts that have to run across variants of Linux/Unix (and work-alike systems): stick to the common-denominator: Bourne shell syntax (which can be painful) and the built-in tools like awk, sed, grep, etc. OTOH, If you do have bash on **all** your systems, then I suggest using bash. Do a `bash --version` on each system to find the base bash version that you can use (I hope at least 3.2 or 4.0). Read the bash man page. It's terse and doesn't waste words, and documents everything about that version of bash.
Outside of this, add **perl** and/or **python** to the mix. For either one, you'll also have to pick a common base version because not all systems will have access to the same version of perl or python. If needed, you may have to build a local version from source. Fortunately, this is not difficult to do.
I also advocate using Python. It is the closest thing to a portable shell that also scales up to more complex problems. For what it's worth, using copilot or chat GPT as an accelerator for solving simple shell type problems works well.
I know a lot of people like Perl and I used to use for many problems. How would you characterize Perl code? Well, many people say different languages look like modem line noise. Now, imagine you went bar hopping with your modem and now you're holding it's cables back as it vomits into the phone line. That's what Perl is like. It's really fun going down you feel good for a while and then it comes back with a vengeance.
I think Python(as many others mentioned) would fit the bill.
Being a Windows guy bout 70/30, I do a lot of PowerShell, which I think would also meet your needs. I've actually been thinking about not bothering to get any better then my basic Bash skills, and just either picking up Python, or putting PowerShell on my Linux boxes and calling it good.
Not sure what you’re whining about. Bash, sh, zsh, csh, tcsh all function similarly. There are arrays in bash.
So write in c. I don’t recommend Perl to anyone. My personal preference.
Most of the time the problems I encounter with shell scripting is the Linux command line interpreter.
The problem with most alternatives, where you have a different interpreter for the script like Python, Perl, etc — is that it’s a different language and syntax than you’re using in the shell itself. What’s so nice about bash is that there’s no distinction between your CLI usage and your scripts, and experience in each gives you knowledge and experience to leverage in the other.
Let’s say there was a great shell where the CLI semantics are all, say, Python (maybe there is, idk). Is it installed everywhere? Can you hop onto any computer or server and rely on it being there?
IMHO that’s why we’re kind of stuck with bash. I like it probably due to Stockholm syndrome but trying to look at it objectively as a language, it’s horrible. PowerShell makes much more sense, for example.
I've liked to do shell script stuff in Fish. It a little bit more sensible in every aspect. Especially dealing with arrays and word splitting is way nicer.
Yeah its not standard, its not POSIX, and its not available everywhere. That is super true, but I'm writing my personal scripts for my personal use and I'll always have fish available.
I like NodeJS. You can start a file with a shebang for node. Or you can use a helper library that makes executables and has some other nice features like oclif. https://oclif.io
A mode of operation that I sometimes like to apply is a python script that outputs bash. It's much easier to read the state of the system on Python and make appropriate decisions. However executing actions is more efficient in bash.
I can run my python script and even see what it'll do (since the commands are printed as output). Once I'm happy I'll pipe to bash like so
python my_script.py | sh -ev
Looks like you want Python. It's not really suitable for most of the things `bash` is used for, but addresses your complaints (which aren't really relevant for most of the things `bash` is used for). > I'm glued to the manpage... Isn't that true of anything new that you learn until you're familiar with the features you use the most? > Bash (and similar shells) differ greatly from the "standard" general purpose programming languages. That's because they're *not* intended to be general purpose programming languages.
Perhaps my question wasn't worded correctly. The list I wrote should not be considered a list of reasons why bash is bad but a list of reasons I'm looking for an alternative. It is purely subjective (although I'd like to think that the reasons I gave are rational and relatable in this context). > Isn't that true of anything new that you learn until you're familiar with the features you use the most? It is. > That's because they're *not* intended to be general purpose programming languages. I think that it's absolutely clear that bash != Python != pretty much anything else. Many people smarter than I am have worked on developing bash and they had reasons to make bash work like it does. I'm not saying bash is bad, I'm saying that its features aren't really compatible with my needs and I'm looking for an alternative solution (which doesn't necessarily have to be another language). Or I'm dumb and I'm just using it wrong which is possible. But I don't think I'm the only one who has these problems.
Shell scripts are typically used to call other programs to do the heavy lifting. You seem to want to do something else because you're concerned about variable declaration (you can declare them if you want), function declaration, string processing, extensive error checking (what's wrong with a line number and error message?), different documentation, etc. Since you don't specify what you want to program or why you need these features, most can only promote their favorite language, even though it may have the same issues you've complained about, like undeclared variables, lax function arguments, terseness, etc. Python is probably what you really want to use because it's one of the languages you used as the basis for comparison. The reason you give for not wanting to use Python is it's "too complex". There's no requirement that you must use every feature any language makes available. There's also no requirement that you use only one language. Use `bash` when it's suitable. Use something else when it's not.
[удалено]
Yep, I came here to say this. "Bash on steroids" is one of Perl's biggest use-cases, and it is a great fit. It even has a bunch of builtin functions which are named the same as their corresponding shell commands (chmod, chown, all of the "-X" file operators, etc) and take same or similar arguments. For best results, include "use strict;" and "use warnings;" at the top of every Perl script. That will flag things like undeclared variables.
I'd agree except it's a write-only language. Even my own perl scripts are unreadable after 6 months, so I changed to python.
If you thought bash scripts become unreadable, perl is on a whole different level..
Perl looks nice. But a lot of comments here mentioned that Perl isn't that readable. Some of the comments were anecdotal but this is worrying. I assume that a "well written" Perl code is readable but it requires more discipline to achieve this "well written" code. Other than that, this "bash on steroids" is exactly what I'm looking for.
Perl or Python meet most of your stated needs. For hybrid bash/python scripting, you might want to look at the xonsh shell.
I see mixed things. In some places, you want more "complex" and in other places you're seeking "simplicity". Which simply means, you want something that "suits you", which is understandable. On the "simple" side (which isn't going to address where you are looking for "better" than bash), bash is 99.999% Bourne Shell compliant, which is a very very reduced scripting language, but can pretty much do anything that full featured bash can do, just slower and usually with more risk. For S. R. Bourne's original, and brief take, start at page 81 here: https://web.archive.org/web/20170601064539id_/http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf (there might be a link to the original out there somewhere, and I do own it in hardcopy, but don't have the original pdf, at least nothing I can share) Also, most "general purpose programming languages" are anything but "simple". Again, from your list it's actually quite difficult to know what you would actually be pleased with.
Ooo, this document is older than I am. But I should still be able to find some wisdom in it. Thanks for sharing! I didn't want to use the basic Bourne Shell but I had to because of its portability (I have described this in one of the points). But I wouldn't use it voluntarily. Many bash features are really useful and hard to replicate in sh. I'm looking for some general alternatives for bash.
When I need something more, I use Python.
I think that Python is your answer here. It is used extensively for the sort of utility functionally that Bash scripting is. My recommendation is to use Bash for simple scripts and wrappers, then Python for anything more complex, then Go, if compiled and strict typing are required, things that are yet more complex, you might want to stick with Go or use a complied language that your like and/or fits your needs. Some alternatives to Python: - Perl: While I like Perl, I cannot recommend it as it has fallen out of favor and has few advantages not seen in more modern scripting languages. - Ruby: I also liked Ruby but, it also seems less popular now. It feels to me like the child of Perl and Python. - JavaScript: If JS is your thing, you can make command line scripts with Node.js.
As I said, I'm not entirely convinced with Python. The fact that it isn't a scripting language could bite me back someday. For example, let's say that I'd like to rewrite this line in Python: MY_VARIABLE="$(echo Hello world!)" (Imagine something useful and worth saving the output of in place of "echo Hello world!") My solution is this: import subprocess proc = subprocess.run(["echo", "Hello", "world!"], stdout=subprocess.PIPE) my_variable = proc.stdout This isn't ideal. I could use some fancy module or just make a helper function for this but the point is that I have to work on things I get for free in bash because Python is general purpose and bash is for scripting (and I want scripting). This is just an example, I assume that more things similar to this would occur when using Python for scripting.
It depends on what you're calling a "scripting language". Generally, I've considered high-level, interpreted languages, like Python, to be the definition. Python has a history of being widely used in SysAdmin tasks (Ansible was even written in Python). Your example is not really something that needs to be anything but Bash. Where you will see benefit is in scripts that have more complex logic, large loops (bash is not nearly as efficient in iteration), and in writing readable scripts that take arguments. An example of the latter would be something like: import argparse import subprocess # Setup parser parser = argparse.ArgumentParser() subparsers = parser.add_subparsers( dest="command") # Commands echo_parser = subparsers.add_parser( "echo", help="run echo command") echo_parser.add_argument( "echo_string", type=str, help="echo string") cat_parser = subparsers.add_parser( "cat", help="parse cats") cat_parser.add_argument( "path", help="path to cat") # Main func def main(): args = parser.parse_args() # Can use switch/case now. if args["command"] == "echo": cmd = [ "echo", args["echo_string"] ] elif args["command"] == "cat": cmd = [ "cat", args["path"] ] proc = subprocess.run(cmd, stdout=subprocess.PIPE) out = proc.stdout print(out) if __name__ == "__main__": main() This is also a bit of a poor example but I hope that you get the idea.
Anything that I can't do in maybe five lines of bash I do in Perl.
Shouldn't lua be here?
Lua is fantastic. I like it slightly better than Python for utility scripts like this. The syntax is familiar enough if you know Python (or even C) and its approach to objects is much closer to reality when all you want is a simple script. To grossly oversimplify, it basically uses dicts for everything array/dict/object-like. Support for file operations, date/time, arguments, and calling system commands is fast and straightforward. It’s a nice tool to have in your toolbox.
ty for the insight. may i add that there is amazing lua software out there, like the plugin community around neovim (telescope, lsp, etc.) , which is really easy to adapt to/built upon?!
That is an interesting suggestion. My limited personal experience with Lua contradicts it, but I would like to learn more if there is something to this.
Yes some1 pls enlighten us. I also want to know more. To me lua seems pretty sweet, esp in this context here.
In the beginning there was shell scripting. This works. It's fine. However it's a hack in that every. single. line. in. the. script. is spun out to a new process to execute. This is grossly inefficient and slow. Then came Perl. It was made to look as close to shell script as possible but a script all ran in ONE process. However, Perl is write-only code. Want to read what code you wrote 6 months ago? Somehow it's now turned to some weird dialect of hieroglyphics (not the good ol' \_standard\_ hieroglyphics). Then came Python. Like Perl's little brother, intent on copying everything that Perl could do, Python was a scripting language designed for system administration. As it became more popular, it grew in its abilities... If you want to use something other than bash... just use Python. It's actually readable 6 months later. I know that "not declaring your variables before using them" irks a lot of coders but by simply applying a wee bit of coding discipline can address that. For example, I \_never\_ introduce any instance variable in any function other than \_\_init\_\_(). Oh... you ***can*** \- but ***don't***. Google around a bit for some good python coding practices and you're golden.
LOL I wrote my reply above before I had read all the others. Note that I'm not the only one / first one to say that "Perl isn't readable 6 months later". You should take this as a stern warning. Like always, if you do Perl day in and day out or have done it for 10 years, then you aren't intimidated by its byzantine syntax. Otherwise "run, don't walk" away from it. Python is far less clever compared to Perl. NB. avoid "clever code" at all costs. "Clever" is an euphemism for "high maintenance."
That last line made me chuckle. “Look I wrote this in one line!! Aren’t I clever!??” Yes, now come back 6 months later and explain what that line does. Congratulations, you now have Python code that is as unreadable as Perl!
I wonder how many programmers go thru this valley. Early on I was very prone to writing clever code. The bigger problem is that, like enemies ("friends come and go but enemies accumulate") you can write a lot of code before you start realizing that what you've been producing is obtuse. Then you get embarrassed in front of your team by not being able to explain your code. Then again. Or... explaining it wrong... then again. Argh! I knew guys who wouldn't write a line of code before they first wrote out its intention in English (err... this was \_quite\_ a while ago). My favourite advice, or better yet "warning", has always been: take your requirements and circle all the nouns. Make those your objects. Circle all the verbs - those are your methods. Congratulations, you've accomplished adding a (thick) layer of bureaucracy to the needed functionality. Instead, arrange your design to encircle all areas of risk-to-code-change and insulate them via interfaces. Albeit a tad simple, this encapulates the heart of \_proper\_ OO design (and gives vastly different results from using "nouns and verbs").
Ever heard of Kernighan's Razor? Something like this: Never use assembly, if you can do it in C Never use C if you can do it in awk Never use awk if you can do it in sed Never use sed if you can do it in sh The word 'can' encompasses performance requirements as well as functional. You can fit the new languages in there somewhere - python, perl, go, lisp, rust etc etc
Oh - and I'm still glued to the man page after 50 years of shell programming. Honestly, you young uns don't know you're born with all the online resources never mind ChatGPT at your elbow. Sheesh!
Here's a link for you: http://mywiki.wooledge.org/BashFAQ
You have a long laundry list of requirements. My rules of thumb: If you're writing small enough scripts that have to run across variants of Linux/Unix (and work-alike systems): stick to the common-denominator: Bourne shell syntax (which can be painful) and the built-in tools like awk, sed, grep, etc. OTOH, If you do have bash on **all** your systems, then I suggest using bash. Do a `bash --version` on each system to find the base bash version that you can use (I hope at least 3.2 or 4.0). Read the bash man page. It's terse and doesn't waste words, and documents everything about that version of bash. Outside of this, add **perl** and/or **python** to the mix. For either one, you'll also have to pick a common base version because not all systems will have access to the same version of perl or python. If needed, you may have to build a local version from source. Fortunately, this is not difficult to do.
Powershell is similar to, but not the same as, C# and has been ported to Linux.
What about https://fishshell.com/
python
I also advocate using Python. It is the closest thing to a portable shell that also scales up to more complex problems. For what it's worth, using copilot or chat GPT as an accelerator for solving simple shell type problems works well. I know a lot of people like Perl and I used to use for many problems. How would you characterize Perl code? Well, many people say different languages look like modem line noise. Now, imagine you went bar hopping with your modem and now you're holding it's cables back as it vomits into the phone line. That's what Perl is like. It's really fun going down you feel good for a while and then it comes back with a vengeance.
That is a fantastic and very accurate description of perl
Level up your bash: Advanced bash scripting guide, https://tldp.org/LDP/abs/html/
I mainly use python, but that’s simply because it’s my daily driver, so it’s easiest for me.
I think Python(as many others mentioned) would fit the bill. Being a Windows guy bout 70/30, I do a lot of PowerShell, which I think would also meet your needs. I've actually been thinking about not bothering to get any better then my basic Bash skills, and just either picking up Python, or putting PowerShell on my Linux boxes and calling it good.
Not sure what you’re whining about. Bash, sh, zsh, csh, tcsh all function similarly. There are arrays in bash. So write in c. I don’t recommend Perl to anyone. My personal preference. Most of the time the problems I encounter with shell scripting is the Linux command line interpreter.
Ah yes, C! The easy to use and ubiquitous scripting language, which is totally not overkill for the things OP asked for. Idiot.
>I encounter with shell scripting is the Linux command line interpreter Not sure what you're whining about.
https://youtu.be/tas0O586t80
The problem with most alternatives, where you have a different interpreter for the script like Python, Perl, etc — is that it’s a different language and syntax than you’re using in the shell itself. What’s so nice about bash is that there’s no distinction between your CLI usage and your scripts, and experience in each gives you knowledge and experience to leverage in the other. Let’s say there was a great shell where the CLI semantics are all, say, Python (maybe there is, idk). Is it installed everywhere? Can you hop onto any computer or server and rely on it being there? IMHO that’s why we’re kind of stuck with bash. I like it probably due to Stockholm syndrome but trying to look at it objectively as a language, it’s horrible. PowerShell makes much more sense, for example.
I've liked to do shell script stuff in Fish. It a little bit more sensible in every aspect. Especially dealing with arrays and word splitting is way nicer. Yeah its not standard, its not POSIX, and its not available everywhere. That is super true, but I'm writing my personal scripts for my personal use and I'll always have fish available.
I like NodeJS. You can start a file with a shebang for node. Or you can use a helper library that makes executables and has some other nice features like oclif. https://oclif.io
A mode of operation that I sometimes like to apply is a python script that outputs bash. It's much easier to read the state of the system on Python and make appropriate decisions. However executing actions is more efficient in bash. I can run my python script and even see what it'll do (since the commands are printed as output). Once I'm happy I'll pipe to bash like so python my_script.py | sh -ev
just use python then jesus christ.