I consider myself to be quite proficient in bash. I write a lot of bash professionally. I've written a compiler (transpiler?) for a strongly typed configuration language that outputs bash.
There are three main problems I see here.
(1) Pipelines, subshells, and external dependencies.
The example on the website compiles a conditional `if age < 18` into this monstrosity:
if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\.\{0,1\}0\{1,\}$//') != 0 ]
Pipelines and subshells are "slow". Not tremendously. But it adds up. Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable:
if (( __0_age < 18 ))
Perfectly fine to alert users that floats will require an external dependency (such as dc), but integers will be handled in native arithmetic contexts.
Seems mildly insane that a conditional this simple would require a pipeline including `echo`, `bc`, and `sed`. Now the user needs to ensure the correct external CLI tools are installed, and match the expected versions. Hope they account for BSD vs. GNU variants. Eek.
(2) Namerefs.
> Arrays cannot be nested due to the Bash limitations
Arrays absolutely can be nested... with some trickery. Consider:
# Top level array w/ pointers to children.
declare -a arr1=( arr2 arr3 )
# Child arrays.
declare -a arr2=( item1 item2 )
declare -a arr3=( item3 item4 )
for ref in "${arr1[@]}" ; do
declare -n sub_array="$ref"
printf '%s\n' "${sub_array[@]}"
done
This is a fairly trivial operation that I'd assume the authors would know about. It's fast and allows for the creation of arbitrarily complex objects. Even rudimentary classes.
(3) Just learn bash.
I'm perpetually confused by people taking every opportunity to not just... learn bash. An otherwise skilled programmer will somehow forget everything they've learned when beginning a shell script.
Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is?
There are many reasons why it is to be avoided.
For me the deal breaker was that one time I spent 2h debugging a script only to find out there was an extra space character that made the whole thing break silently.
I would be willing to learn a sane language, but bash isn't one. If you need to know of a million tiny gotchas to implement even the simplest task safely and portably, then there isn't any reason to _learn_ bash.
> I spent 2h debugging a script only to find out there was an extra space character that made the whole thing break silently.
When I was learning C++, I lost 2 days because of an extra ";" in an if statement. However this does not mean C++ is an insane language. It means it has quirks.
> I would be willing to learn a sane language, but bash isn't one
I kindly, but strongly disagree.
> If you need to know of a million tiny gotchas to implement even the simplest task safely and portably
Then you'd absolutely hate Perl, to the level of pulling your or The Camel's hairs out.
This is how programming languages work. They have straights and curvy parts, and there are some chicanes (quirks). So yeah, if you need to use bash, you need to learn it.
You're right. To be fair, I'm absolutely immune to these kinds of quirks in any technology, and just adapt. This causes me to dislike no languages, and just work with them if they fit to the problem I have at hand.
This trait baffles a couple of my friends with no end.
> need to know of a million tiny gotchas to implement even the simplest task safely and portably
While this is clearly exaggeration, I'm not sure I find much merit in the argument.
C is full of gotchas, footguns, and a tremendous threat vector. But it is also the standard for many uses.
Yes, bash has legacy cruft, and potentially confusing ways of doing things. But for the realm in which it operates, it is extremely effective. We can make an argument for what we believe the perfect shell scripting language would be--but that doesn't exist. Bash is the current tool for addressing this category of problems.
The intention of this bullet point was to illustrate that just as I wouldn't work in an industry/role requiring C tools, and instead turn to some weird, novel, riddled-with-problems transpiler... I'd just learn C.
(P.S., bats[0] and shellcheck[1] address many problems noted in this thread.)
> While this is clearly exaggeration, I'm not sure I find much merit in the argument.
>
> C is full of gotchas, footguns, and a tremendous threat vector. But it is also the standard for many uses.
(I'm not GP)
Yes, and the same way there's a plethora of bash-alternatives in the making, there are multiple languages trying to essentially be a "better C", such as Go, Rust and so on, not to mention C++ and its descendants.
I definitely think there's room for an improved bash. The biggest question is whether an alternative can become ubiquitous enough to be a fully qualified alternative.
> I definitely think there's room for an improved bash.
Absolutely! I wholeheartedly agree, and would love for such a project to exist, and see sufficient adoption such that it's a standard at my job.
I may not have articulated my prior point precisely enough.
Too often I'll see a professional JS programmer (for example) who will forego everything they've learned the second they touch a shell script. No useful comments, no functions, poor design & implementation, no care towards idioms, no regard for readability/maintainability.
Given that bash is currently the standard, someone is better served by actually learning it than a worse, novel alternative.
Any successor must encompass the power and feature-set that exists within contemporary shell scripting.
The reason why it is attractive is to enable people who aren't ever going to get proficient at writing/debugging bash/sh to the level that you're at, to write enough bash/sh to get their jobs done both quickly and safely.
The majority of people doing DevOpsey kind of stuff aren't remotely experts with what they're working on, and won't ever be experts, but work still needs to get done.
Maybe if those people started visibly failing at their jobs, they'd either upskill or be forced out, and then the magical hand of the market would raise salaries for the rest of us.
Oh look you're basically me in 2006 thinking that all the sysadmins that couldn't be bothered to learn a real programming language needed to be replaced by people in India who weren't intellectually lazy (because I was a bit of an asshole and wrong).
As carlinigraphy points out, shellcheck [0] exists, and can easily be put into pre-commits, a CI pipeline, etc. This would have almost certainly flagged your problem immediately.
> I would be willing to learn a sane language, but bash isn't one.
It's a general language that has to be both an interactive interpreter and script executor, and it needs to support a huge variety of architectures and kernel versions, as well as historical decisions. It's going to have some cruft.
> There are many reasons why it is to be avoided. For me the deal breaker was that one time I spent 2h debugging a script only to find out there was an extra space character that made the whole thing break silently.
This sounds like using `a = b` instead of `a=b`, something you learn in an introductory Bash tutorial. It's not a good argument to say "I didn't learn Bash and it cost me 2 hours, therefore I should continue to not learn Bash."
Have learned a bit of bash but that's what has kept me going on always. There's no point in learning million little inconsistencies all of which aren't even documented anywhere like a MDN or MSDN if you will.
But you don't really need to spend any time learning them, just plug shellcheck itself into your editor and go write some scripts. I've written don't know how many thousands of lines of bash (and sh, depending on the task at hand) that work across five operating systems, and it's honestly a non-issue if you follow the warnings.
That's about where I gave up too. You make it sound like you disagree with me when in reality you do.
There is no real reason to write any production code in bash or any other shell language.
Bash is for automation, not building services. It's used heavily in sys admin and devops tasks
The reason to learn it is that it can make your dev experience better. Make falls into this category as well. Both are great ways to combine multiple tools together.
That being said, I'm using more Dagger for this purpose these days, which provides you SDKs for your fav langs.
You know that your shell environment is not forced on you, right? You can just switch to ZSH, fish, etc.
The only time this complaint is valid is if you're in a professional environment and you're not allowed to use alternate shells in your account, for some reason.
> The OP was explicitly speaking about using it a professional setting.
Note the little asterisk at the end there?
I've worked as a systems administrator/engineer and a DevOps Engineer at quite a few companies. Very few of them cared what shell your personal account used (and usually had zsh, if not also fish). And they wouldn't run shell scripts in production; but if they did allow that, they probably wouldn't care which one you included in your shebang (as long as the package was in our standard deploy set).
Obviously that doesn't represent all places, thus why I added the caveat. However, the number of places that A) allow you to run shell scripts in production and B) are also so overly paranoid as to limit user account shell interface are probably the exception, not the rule.
Agreed. For instance, the piped bc sed thing's error handling is apparently broken, and no one has pointed that out yet. pipefail and $() don't play nice with each other:
#!/bin/bash
set -euo pipefail
echo $(false|true)
echo a
echo $(false)
echo b
false
echo c
I've done (some? a lot?) of bash scripting and failing correctly in the absence of dependencies is really important. And once you've incorporated them you've destroyed what was good about targeting bash in the first place, because you're back to giving the user a configuration management problem, and if you were going to do them, you might as well have them install $better_language anyway.
Per docs[0], seems types are rudimentary. For numerics there's only one type for any number. Good remark regarding GNU vs others. This isn't seem be noted anywhere.
> Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is?
I've been using GNU/Linux for ~10 years, and Bash never clicked for me. Meanwhile, picking up other (not all) programming languages in the meantime occurred naturally, without much effort.
At the same time, some of my friends picked up unix shell scripting just fine, even if typical programming is harder for them.
I suspect some people have trouble with the syntax used by Bash, and languages like Perl. But I can't pinpoint what causes it.
Yeah, I stopped reading at that conversion. If it cannot handle a single "<" imagine more complicated logic, it would make debugging it a true nightmare.
My reaction was that the bash version is a monstrosity indeed and I got shudders thinking about being an on-call operator getting a page and then having to read and understand what the hell is wrong with this script.
I consider myself to be quite proficient in bash. I write a lot of bash professionally. I've written a compiler (transpiler?) for a strongly typed configuration language that outputs bash.
There are three main problems I see here.
(1) Pipelines, subshells, and external dependencies.
The example on the website compiles a conditional `if age < 18` into this monstrosity:
Pipelines and subshells are "slow". Not tremendously. But it adds up. Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable: Perfectly fine to alert users that floats will require an external dependency (such as dc), but integers will be handled in native arithmetic contexts.Seems mildly insane that a conditional this simple would require a pipeline including `echo`, `bc`, and `sed`. Now the user needs to ensure the correct external CLI tools are installed, and match the expected versions. Hope they account for BSD vs. GNU variants. Eek.
(2) Namerefs.
> Arrays cannot be nested due to the Bash limitations
Arrays absolutely can be nested... with some trickery. Consider:
The `declare -n` line is where the magic happens: https://www.gnu.org/software/bash/manual/html_node/Shell-Par...This is a fairly trivial operation that I'd assume the authors would know about. It's fast and allows for the creation of arbitrarily complex objects. Even rudimentary classes.
(3) Just learn bash.
I'm perpetually confused by people taking every opportunity to not just... learn bash. An otherwise skilled programmer will somehow forget everything they've learned when beginning a shell script.
Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is?