6 ms·

I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash.

by norir 3y ago

I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.

TonyTrapp 3y ago
That's easier said than done, and completely getting rid of bash may often not be worth the time and effort. But in general I agree, anything remotely complex I try to offload into scripts written in less idiosyncratic languages. Having some tools to help avoiding mistakes with the last 5% that stay bash scripts is super helpful in that case.
avg_dev 3y ago
a part of me agrees with the aim of what you say: why not start afresh with something that is less prone to accidents? and i do agree with that idea. but i think it is also somewhat impractical to ignore that pretty much every server i've ever interacted with has a default, vanilla, bash installed, and if i know how to use that, it helps me get by. not to say we can't and shouldn't try to do better.
Upvoter33 3y ago
If you think this way, you will quickly stop using anything. Most computer things are pretty complex and have really intricate oddities.
- esafak 3y ago
  No, you won't. There are numerous shells that are better. The path to improvement lies in being able to call drek by its name.
scrozier 3y ago
I think this is a valid point. bash is an overly complicated tool...so I'll write another tool on top of that (with none of the decades of debugging that bash itself has undergone) to make bash...LESS complex? The problem is with bash itself. We tend to undervalue ease of use and overvalue "cleverness." Case in point: git. Very clever tool. Ease of use: terrible. But Linus wrote it and Linus is clever, so it must be us that's the problem. We get what we value. Let's value ease of use more.
t43562 3y ago
It has idiosyncracies because it's not a general purpose language. Even the things that she mentions are happening for good reasons - like the fact that set -x would break the expected behavior of || and &&. Actually what language does crash when a function returns false? I mean some throw exceptions but isn't "false" a valid thing to return? I find the same thing with makefiles - people don't understand what they're doing and expect them to work in a certain way because they haven't ever thought about build systems very deeply. Recursive assignment in Make catches almost everyone out e.g. FLAGS=-b COMPILE=compile $(FLAGS) $(info compile command=$(COMPILE)) FLAGS=-a myfile: echo $(COMPILE) $? -o $@ outputs: t43562@rhodes:~ make -f t.mk compile command=compile -b echo compile -a -o myfile compile -a -o myfile Despite this, making all assignments immediate to match other programming languages would take a VERY useful tool away. The more you understand these tools the more you know where to bother using them and how much effort to put into it.
- Izkata 3y ago
  You can get code formatting by indenting it all with 2 spaces.
eviks 3y ago
Indeed, especially now when you have so many great alternatives, use python as your shell if you like Many bad designs are too entrenched to be fixed with some tooling
dgb23 3y ago
Many have tried, nobody succeeded. Bash scripts are extremely useful and productive for their niche. You'd have to change a whole lot of things to match that.
marcosdumay 3y ago
So, you never use bash? That's not a very practical hill to die on. But well, you get to decide what fight you engage on.
justin_oaks 3y ago
I have yet to find a proper replacement for bash. Especially for scripts. The two most common alternatives are 1) using some of the newer shells people have created, like Oil shell [0], or 2) using programming language like Python, JavaScript, or PHP. The problem with using a newer shell is that you'll have to install the new shell anywhere you want to use the script. Meanwhile bash is ubiquitous. Unless you're the only one maintaining the script, you're requiring others to learn the other shell to maintain the script. The problem with using another programming language is that they rarely have good ergonomics for doing what bash does: stringing together commands, command input, command output, and files. If you try to do that in another programming language, things suddenly get a lot more complicate or at least more verbose. So I still use bash, but I recognize that it's strength is in running other commands and dealing with I/O. If I'm doing complicated logic that doesn't involve that, then I'll offload my work to another language. Sometimes that just means calling a python script from bash, not avoiding bash completely. If people found that they work better by taking other approaches, the please share them. [0] https://www.oilshell.org https://www.oilshell.org
- ff317 3y ago
  I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead of Python. Perl5 is pretty much installed everywhere and universally compatible for anything but the very latest language features.
  - abdusco 3y ago
    I usually resort to running inline scripts using python3 or node (using only the standard library) if I need to do something that I can't express in bash easily. That means avoiding stuff that have to look up and I won't remember or be able to debug in a month.
    - 3y ago
Too 3y ago
Yes. While I’m a huge fan of shellcheck and am one who actually have used and know bash deeply. No amount of linters or other tooling on top of bash can fix it. Best solution is to just stay away. For real. Just stop. Don’t try to be macho. The whole model of the language is fundamentally broken. I mean, stringly typed, global mode switches, one-character flags for fundamental comparison operators, defaulting to ignoring errors at every corner you look, functions especially. Each such idiosyncrasy on its own is enough to dismiss such a language, bash has them all plus more.

by norir 3y ago

TonyTrapp 3y ago

That's easier said than done, and completely getting rid of bash may often not be worth the time and effort. But in general I agree, anything remotely complex I try to offload into scripts written in less idiosyncratic languages. Having some tools to help avoiding mistakes with the last 5% that stay bash scripts is super helpful in that case.

avg_dev 3y ago

a part of me agrees with the aim of what you say: why not start afresh with something that is less prone to accidents? and i do agree with that idea. but i think it is also somewhat impractical to ignore that pretty much every server i've ever interacted with has a default, vanilla, bash installed, and if i know how to use that, it helps me get by. not to say we can't and shouldn't try to do better.

Upvoter33 3y ago

If you think this way, you will quickly stop using anything. Most computer things are pretty complex and have really intricate oddities.

esafak 3y ago
No, you won't. There are numerous shells that are better. The path to improvement lies in being able to call drek by its name.

scrozier 3y ago

I think this is a valid point. bash is an overly complicated tool...so I'll write another tool on top of that (with none of the decades of debugging that bash itself has undergone) to make bash...LESS complex? The problem is with bash itself. We tend to undervalue ease of use and overvalue "cleverness." Case in point: git. Very clever tool. Ease of use: terrible. But Linus wrote it and Linus is clever, so it must be us that's the problem. We get what we value. Let's value ease of use more.

t43562 3y ago

It has idiosyncracies because it's not a general purpose language. Even the things that she mentions are happening for good reasons - like the fact that set -x would break the expected behavior of || and &&. Actually what language does crash when a function returns false? I mean some throw exceptions but isn't "false" a valid thing to return? I find the same thing with makefiles - people don't understand what they're doing and expect them to work in a certain way because they haven't ever thought about build systems very deeply. Recursive assignment in Make catches almost everyone out e.g. FLAGS=-b COMPILE=compile $(FLAGS) $(info compile command=$(COMPILE)) FLAGS=-a myfile: echo $(COMPILE) $? -o $@ outputs: t43562@rhodes:~ make -f t.mk compile command=compile -b echo compile -a -o myfile compile -a -o myfile Despite this, making all assignments immediate to match other programming languages would take a VERY useful tool away. The more you understand these tools the more you know where to bother using them and how much effort to put into it.

Izkata 3y ago
You can get code formatting by indenting it all with 2 spaces.

eviks 3y ago

Indeed, especially now when you have so many great alternatives, use python as your shell if you like Many bad designs are too entrenched to be fixed with some tooling

dgb23 3y ago

Many have tried, nobody succeeded. Bash scripts are extremely useful and productive for their niche. You'd have to change a whole lot of things to match that.

marcosdumay 3y ago

So, you never use bash? That's not a very practical hill to die on. But well, you get to decide what fight you engage on.

justin_oaks 3y ago

I have yet to find a proper replacement for bash. Especially for scripts. The two most common alternatives are 1) using some of the newer shells people have created, like Oil shell [0], or 2) using programming language like Python, JavaScript, or PHP. The problem with using a newer shell is that you'll have to install the new shell anywhere you want to use the script. Meanwhile bash is ubiquitous. Unless you're the only one maintaining the script, you're requiring others to learn the other shell to maintain the script. The problem with using another programming language is that they rarely have good ergonomics for doing what bash does: stringing together commands, command input, command output, and files. If you try to do that in another programming language, things suddenly get a lot more complicate or at least more verbose. So I still use bash, but I recognize that it's strength is in running other commands and dealing with I/O. If I'm doing complicated logic that doesn't involve that, then I'll offload my work to another language. Sometimes that just means calling a python script from bash, not avoiding bash completely. If people found that they work better by taking other approaches, the please share them. [0] https://www.oilshell.org https://www.oilshell.org

ff317 3y ago
I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead of Python. Perl5 is pretty much installed everywhere and universally compatible for anything but the very latest language features.
- abdusco 3y ago
  I usually resort to running inline scripts using python3 or node (using only the standard library) if I need to do something that I can't express in bash easily. That means avoiding stuff that have to look up and I won't remember or be able to debug in a month.
  - 3y ago

Too 3y ago

Yes. While I’m a huge fan of shellcheck and am one who actually have used and know bash deeply. No amount of linters or other tooling on top of bash can fix it. Best solution is to just stay away. For real. Just stop. Don’t try to be macho. The whole model of the language is fundamentally broken. I mean, stringly typed, global mode switches, one-character flags for fundamental comparison operators, defaulting to ignoring errors at every corner you look, functions especially. Each such idiosyncrasy on its own is enough to dismiss such a language, bash has them all plus more.