4 ms·

They suggest that based on their experience. Error handling in bash is awful so I advice against using it for anything complex.

by jeltz 2y ago

irunmyownemail 2y ago
Anything complex should be written in a competent language like Java. Script languages (like Bash and Python) are for short (a few lines long) scripts. Using the tool outside the scope of what it was designed for is not a good idea.
- teddyh 2y ago
  Tell me you have never seriously used Python without telling me you have never seriously used Python. I mean, viewing Python strictly as a scripting language? I am honestly lost for words. There are many huge and major applications and web sites written in Python, without people regretting it after the fact. And yet here you are dismissing it out of hand without a single argument.
  - Izkata 2y ago
    Meanwhile most of the time topics like this come up and people hate on shell scripts, those of us that like them see those criticisms the same way you're looking at this comment about python: So far out there it's almost not worth responding. I think that's why GGP and GGGP think "greybeards" don't think it's worthwhile based on experience - it's actually not worth arguing against misinformed comments so newer people don't realize it's still heavily used, just quietly in the background for things it's actually good at. Further down is a comment about that: https://news.ycombinator.com/item?id=42664939 https://news.ycombinator.com/item?id=42664939
    - mturmon 2y ago
      > …not worth arguing against misinformed comments … Yeah, I have these same response patterns. Shell works really well for some use cases. I generally don’t respond to the comments that list the various “footguns” of shell, or that complain about security holes, etc. My use cases are not sensitive to these concerns, and even besides this, I find the concerns overstated.
  - dingnuts 2y ago
    Don't be too rude, this is a common view among people who are technically adjacent but not engineers, like IT people. It's an incorrect superstition, of course, but in tech almost everybody has their superstitions. There's no reason to be rude -- ignorance is not a crime.
    - deleted 2y ago
      [deleted]
  - chillpenguin 2y ago
    I see that kind of thing all the time. Usually it is about static types. People think that dynamic languages aren't "serious", or something. It is laughable that these people still make up a significant amount of comments, here in 2024.
- TypingOutBugs 2y ago
  Why shouldn't you use Python for larger projects, and why do so many startups succeed with large Python repos?
- dotancohen 2y ago
  When my scripts outgrow bash, they almost always wind up in Python. That said, Sonnet 3.5 had gotten me much further in bash than was possible before - and it's all really maintainable too. I highly suggest consulting with Sonnet on your longer scripts, even just asking it "what would you suggest to improve".
- shakna 2y ago
  Using a tool beyond its design can be problematic. But Python is not designed to only be a scripting language: > What is Python? > Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes. It supports multiple programming paradigms beyond object-oriented programming, such as procedural and functional programming. Python combines remarkable power with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C or C++. It is also usable as an extension language for applications that need a programmable interface. Finally, Python is portable: it runs on many Unix variants including Linux and macOS, and on Windows.
superq 2y ago
You can go a really really long way, with a script that will work everywhere, with just set -e and aborting at the first error. Better yet, 'bash unofficial strict mode': set -euo pipefail IFS=$'\n\t'
- shawn_w 2y ago
  That has lots of issues. See https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail for some.
  - sgarland 2y ago
    It does, yes, but IME if you can get people who aren’t familiar with shell to use it, it prevents more problems than it solves on the whole. Then again, so does enforcing passing shellcheck in CI.
  - citrin_ru 2y ago
    One can made arguments both for and against `set -e`. Over may carrier I've seen many shell scripts: The most common case is no `-e` and no explicit error/status checks for most commands. It's unreliable and such scripts is one of reasons why shell got it's bad reputation (and criticized by coders using languages where an unhanded exception would terminate a program). In my own scripts I often use `-e` (but not always as it is a tradeoff). If you unfamiliar with shell `-e` also could cause problems. But `-e` is not magic which makes a script better, one have to know how it works. The option author of this article advocates (no `-e` but explicitly check every command which could fail) is the least common IMHO. Unless the scripts calls just 1-2 commands it's tedious and the resulting script is harder to read. May be you can find such style in some opensource projects but I've never seen such scripts at work.

They suggest that based on their experience. Error handling in bash is awful so I advice against using it for anything complex.

by jeltz 2y ago

They suggest that based on their experience. Error handling in bash is awful so I advice against using it for anything complex.

irunmyownemail 2y ago

Anything complex should be written in a competent language like Java. Script languages (like Bash and Python) are for short (a few lines long) scripts. Using the tool outside the scope of what it was designed for is not a good idea.

teddyh 2y ago
Tell me you have never seriously used Python without telling me you have never seriously used Python. I mean, viewing Python strictly as a scripting language? I am honestly lost for words. There are many huge and major applications and web sites written in Python, without people regretting it after the fact. And yet here you are dismissing it out of hand without a single argument.
- Izkata 2y ago
  Meanwhile most of the time topics like this come up and people hate on shell scripts, those of us that like them see those criticisms the same way you're looking at this comment about python: So far out there it's almost not worth responding. I think that's why GGP and GGGP think "greybeards" don't think it's worthwhile based on experience - it's actually not worth arguing against misinformed comments so newer people don't realize it's still heavily used, just quietly in the background for things it's actually good at. Further down is a comment about that: https://news.ycombinator.com/item?id=42664939 https://news.ycombinator.com/item?id=42664939
  - mturmon 2y ago
    > …not worth arguing against misinformed comments … Yeah, I have these same response patterns. Shell works really well for some use cases. I generally don’t respond to the comments that list the various “footguns” of shell, or that complain about security holes, etc. My use cases are not sensitive to these concerns, and even besides this, I find the concerns overstated.
- dingnuts 2y ago
  Don't be too rude, this is a common view among people who are technically adjacent but not engineers, like IT people. It's an incorrect superstition, of course, but in tech almost everybody has their superstitions. There's no reason to be rude -- ignorance is not a crime.
  - deleted 2y ago
    [deleted]
- chillpenguin 2y ago
  I see that kind of thing all the time. Usually it is about static types. People think that dynamic languages aren't "serious", or something. It is laughable that these people still make up a significant amount of comments, here in 2024.
TypingOutBugs 2y ago
Why shouldn't you use Python for larger projects, and why do so many startups succeed with large Python repos?
dotancohen 2y ago
When my scripts outgrow bash, they almost always wind up in Python. That said, Sonnet 3.5 had gotten me much further in bash than was possible before - and it's all really maintainable too. I highly suggest consulting with Sonnet on your longer scripts, even just asking it "what would you suggest to improve".
shakna 2y ago
Using a tool beyond its design can be problematic. But Python is not designed to only be a scripting language: > What is Python? > Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes. It supports multiple programming paradigms beyond object-oriented programming, such as procedural and functional programming. Python combines remarkable power with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C or C++. It is also usable as an extension language for applications that need a programmable interface. Finally, Python is portable: it runs on many Unix variants including Linux and macOS, and on Windows.

superq 2y ago

You can go a really really long way, with a script that will work everywhere, with just set -e and aborting at the first error. Better yet, 'bash unofficial strict mode': set -euo pipefail IFS=$'\n\t'

shawn_w 2y ago
That has lots of issues. See https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail for some.
- sgarland 2y ago
  It does, yes, but IME if you can get people who aren’t familiar with shell to use it, it prevents more problems than it solves on the whole. Then again, so does enforcing passing shellcheck in CI.
- citrin_ru 2y ago
  One can made arguments both for and against `set -e`. Over may carrier I've seen many shell scripts: The most common case is no `-e` and no explicit error/status checks for most commands. It's unreliable and such scripts is one of reasons why shell got it's bad reputation (and criticized by coders using languages where an unhanded exception would terminate a program). In my own scripts I often use `-e` (but not always as it is a tradeoff). If you unfamiliar with shell `-e` also could cause problems. But `-e` is not magic which makes a script better, one have to know how it works. The option author of this article advocates (no `-e` but explicitly check every command which could fail) is the least common IMHO. Unless the scripts calls just 1-2 commands it's tedious and the resulting script is harder to read. May be you can find such style in some opensource projects but I've never seen such scripts at work.