6 ms·
To my eye, this does not look good. I consider myself to be quite proficient in bash. I write a lot of bash professionally. I've written a compiler (transpiler
by carlinigraphy 2y ago
To my eye, this does not look good.
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
The `declare -n` line is where the magic happens: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameters.html 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?
- forgotpwd16 2y ago>having types in your language 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. [0]: https://docs.amber-lang.com/basic_syntax/data_types https://docs.amber-lang.com/basic_syntax/data_types
- viraptor 2y ago> Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable: I would expect it uses bc instead of relying on bash's environment/version-dependent 32/64bit integers.
- jnsaff2 2y agoMy 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.
- mywittyname 2y ago> ... learn bash. I've been writing bash code regularly for my entire 20 year career. I'm not convinced that I've "learned bash" yet. Bash has too many different ways of doing things, and it can be hard to determine which variant is the right way.
- hedora 2y agoAgreed. 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 Prints 'ab'.
- partdavid 2y agoI'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.
- gr4vityWall 2y ago> 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.
- xandrius 2y agoYeah, I stopped reading at that conversion. If it cannot handle a single "<" imagine more complicated logic, it would make debugging it a true nightmare.
- xnickb 2y ago> Just learn bash. 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.
- wg0 2y agoHave 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.
- 5e92cb50239222b 2y agoMost are documented by shellcheck. https://gist.github.com/nicerobot/53cee11ee0abbdc997661e65b348f375#file-_shellcheck-md https://gist.github.com/nicerobot/53cee11ee0abbdc997661e65b3... 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.
- xnickb 2y agoThat'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.
- verdverm 2y agoBash 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.