5 ms·

> 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 th

by 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 ago
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.
- 5e92cb50239222b 2y ago
  Most 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 ago
  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.
  - verdverm 2y ago
    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.
deaddodo 2y ago
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.
- xnickb 2y ago
  > The only time this complaint is valid I've dealt with bash scripts running in high load production systems and I'm very happy I don't have to any more. There is a reason my comment was a response and not a standalone statement. The OP was explicitly speaking about using it a professional setting.
  - deaddodo 2y ago
    > 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.
bayindirh 2y ago
> 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.
- samatman 2y ago
  > However this does not mean C++ is an insane language. It means it has quirks. Any sufficiently quirky technology is indistinguishable from insanity. https://yosefk.com/c++fqa/index.html https://yosefk.com/c++fqa/index.html
  - bayindirh 2y ago
    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. BTW, That's a great link. Thanks a lot.
    - deleted 2y ago
      [deleted]
  - nativeit 2y ago
    C++ is not dead, it just smells funny. Thanks for this time sink.
xdennis 2y ago
> 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."
carlinigraphy 2y ago
> 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.) [0] https://github.com/bats-core/bats-core [1] https://www.shellcheck.net/
- 8372049 2y ago
  > 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.
  - lamontcg 2y ago
    bash isn't even ubiquitous enough to be a fully qualified alternative. people still get paid to care about things like solaris 9 and aix 6.
  - carlinigraphy 2y ago
    > 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.
sgarland 2y ago
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. [0]: https://www.shellcheck.net/ https://www.shellcheck.net/

by xnickb 2y ago

wg0 2y ago

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.

5e92cb50239222b 2y ago
Most 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 ago
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.
- verdverm 2y ago
  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.

deaddodo 2y ago

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.

xnickb 2y ago
> The only time this complaint is valid I've dealt with bash scripts running in high load production systems and I'm very happy I don't have to any more. There is a reason my comment was a response and not a standalone statement. The OP was explicitly speaking about using it a professional setting.
- deaddodo 2y ago
  > 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.

bayindirh 2y ago

> 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.

samatman 2y ago
> However this does not mean C++ is an insane language. It means it has quirks. Any sufficiently quirky technology is indistinguishable from insanity. https://yosefk.com/c++fqa/index.html https://yosefk.com/c++fqa/index.html
- bayindirh 2y ago
  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. BTW, That's a great link. Thanks a lot.
  - deleted 2y ago
    [deleted]
- nativeit 2y ago
  C++ is not dead, it just smells funny. Thanks for this time sink.

xdennis 2y ago

> 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."

carlinigraphy 2y ago

> 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.) [0] https://github.com/bats-core/bats-core [1] https://www.shellcheck.net/

8372049 2y ago
> 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.
- lamontcg 2y ago
  bash isn't even ubiquitous enough to be a fully qualified alternative. people still get paid to care about things like solaris 9 and aix 6.
- carlinigraphy 2y ago
  > 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.

sgarland 2y ago

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. [0]: https://www.shellcheck.net/ https://www.shellcheck.net/