4 ms·

Bash is low on the list of things to learn, especially as many greybeards suggest keeping on POSIX compatibility and/or using a "proper" language (Python, older

Bash is low on the list of things to learn, especially as many greybeards suggest keeping on POSIX compatibility and/or using a "proper" language (Python, older: Perl) for anything longer than a few lines.

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.
superq 2y ago
Give bash some credit - it's actually amazing for even very large, complex systems (of which there are many -- quietly doing their jobs for decades.) With xargs or GNU parallel, you can have multi-processing, too. Combining with curl or ffmpeg, you can literally build a production-grade web scraper or video transcoding pipeline in a couple of minutes and a few dozen lines of code.
dolni 2y ago
I write a lot of shell and my advice is don't use plain POSIX shell. Write bash. It is 2025. bash is present almost everywhere. If, by chance, your script is run somewhere that doesn't have bash then guess what? Your POSIX script probably won't work anyway. It will be a different system, with different utilities and conventions. Line count is not a good reason to choose or avoid bash. Bash is quite reliably the lowest common denominator. I dare say it is even the best choice when your goal is accomplished by just running a bunch of commands. All that said, bash is gross. I wish we had something as pervasive that wasn't so yucky.

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.

superq 2y ago

Give bash some credit - it's actually amazing for even very large, complex systems (of which there are many -- quietly doing their jobs for decades.) With xargs or GNU parallel, you can have multi-processing, too. Combining with curl or ffmpeg, you can literally build a production-grade web scraper or video transcoding pipeline in a couple of minutes and a few dozen lines of code.

dolni 2y ago

I write a lot of shell and my advice is don't use plain POSIX shell. Write bash. It is 2025. bash is present almost everywhere. If, by chance, your script is run somewhere that doesn't have bash then guess what? Your POSIX script probably won't work anyway. It will be a different system, with different utilities and conventions. Line count is not a good reason to choose or avoid bash. Bash is quite reliably the lowest common denominator. I dare say it is even the best choice when your goal is accomplished by just running a bunch of commands. All that said, bash is gross. I wish we had something as pervasive that wasn't so yucky.