4 ms·

> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language

> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language and still worth learning. The number of ~/.claude/settings.json I've seen with "permissions": { "allow": ["Bash(find *)"]} I've seen is crazy[1]. Hell, most people I talk to think `find` is a tool that is used for searching for files. I mean... it does that... along with arbitrary code execution ¯\_(ツ)_/¯ [0] https://mywiki.wooledge.org/BashPitfalls https://mywiki.wooledge.org/BashPitfalls Edit: [1] Fuck it, here's the lazy search: https://github.com/search?q=%22Bash(find%20*)%22&type=code https://github.com/search?q=%22Bash(find%20*)%22&type=code

ashwin42 2mo ago
over 30 years ago bash was magic for us oldies :-D
doublerabbit 2mo ago
> It is a terrible language It's not. It only becomes terrible when you misuse for it's original purpose. Microsoft Excel isn't terrible, but the way it gets used makes it terrible.
- zbentley 2mo ago
  No, it is terrible. The entire reason things like Fish annd PowerShell exist is because bash (and POSIX sh language broadly) are garbage even for their original purpose. Maybe it had to be that way because we didn’t know any better or needed to preserve historical semantics. But that doesn’t make it good. Word splitting. Pipefail. Quoting hell. Scoping. On-error-resume-next by default. Returning values implemented like errno. Perlish cryptic tenseness around basic string manipulation/arrays. Magic global variables that don’t behave like other variables. Argument unpacking and shift. These are bad language features, and people trip over them constantly. Even when they’re only using bash as an interactive shell or a <10 line snippet runner.
  - doublerabbit 2mo ago
    And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Perl comes close and it's one of my favourite languages. Even back then it was archaic. Maybe we can agree on Tcl.
    - zbentley 2mo ago
      > And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Like I said: > Maybe it had to be that way because we didn’t know any better … But that doesn’t make it good. I’ve gotten kind of pointlessly good at bash tricks—the weird advanced shit that Wooledge warns about. Same for Perl5: 6 years on a multimillion line healthcare monolith wishing for a real object system, a single scoping model instead of three, and people to stop implementing rickety DSLs because the language was just flexible enough to let them but not flexible enough to make the tooling or DX any good. All of which is to say: I get it. Those languages were some of the first I learned, and hold a charming sort of nostalgia for me as well. They are still objectively bad. We have vastly better tools now in those niches.
      - doublerabbit 2mo ago
        > We have vastly better tools now in those niches. But do we? I'll beg to differ. Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require. If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed timely manner in cron, it works just fine. The overhead of using languages compared to the previous is partly why I keep using bash or Tcl.
        akdev1l 2mo ago
        from subprocess import run from sys import argv source = argv[1] destination = argv[2] run([ "rsync", "-zavp", source, destination ]) vs #!/usr/bin/env bash source="$1" destination="$2" rsync \ -zavp \ "$source" \ "$destination" the overhead is not really that bad imo
- godelski 2mo ago
  I love bash. I write a lot of bash too. It is a extremely powerful and useful language. But that also doesn't mean it is a good language. There are many non-intuitive things, hence that pitfalls page I linked. You can't just deflect and say that the user is "holding it wrong". If it is difficult and unintuitive in how to "hold" it correctly, that's a design problem, not a user problem. Despite bash being a terrible language, I still use it on a daily basis because it is useful. But don't conflate these things.
isityettime 2mo ago
`find` isn't a Bash built-in and has basically nothing to do with Bash as a language. Not knowing `find` is a basic Unix literacy issue, not a Bash language footgun. You're right that Bash is full of footguns, especially around quoting. And you're also right that that issue is even worse— and I think it's somewhat representative. Some of the cited Bash footguns are also about general lack of familiarity with CLI conventions and stringly typed data generally, like the dirname quoting issue.

ashwin42 2mo ago

over 30 years ago bash was magic for us oldies :-D

doublerabbit 2mo ago

> It is a terrible language It's not. It only becomes terrible when you misuse for it's original purpose. Microsoft Excel isn't terrible, but the way it gets used makes it terrible.

zbentley 2mo ago
No, it is terrible. The entire reason things like Fish annd PowerShell exist is because bash (and POSIX sh language broadly) are garbage even for their original purpose. Maybe it had to be that way because we didn’t know any better or needed to preserve historical semantics. But that doesn’t make it good. Word splitting. Pipefail. Quoting hell. Scoping. On-error-resume-next by default. Returning values implemented like errno. Perlish cryptic tenseness around basic string manipulation/arrays. Magic global variables that don’t behave like other variables. Argument unpacking and shift. These are bad language features, and people trip over them constantly. Even when they’re only using bash as an interactive shell or a <10 line snippet runner.
- doublerabbit 2mo ago
  And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Perl comes close and it's one of my favourite languages. Even back then it was archaic. Maybe we can agree on Tcl.
  - zbentley 2mo ago
    > And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Like I said: > Maybe it had to be that way because we didn’t know any better … But that doesn’t make it good. I’ve gotten kind of pointlessly good at bash tricks—the weird advanced shit that Wooledge warns about. Same for Perl5: 6 years on a multimillion line healthcare monolith wishing for a real object system, a single scoping model instead of three, and people to stop implementing rickety DSLs because the language was just flexible enough to let them but not flexible enough to make the tooling or DX any good. All of which is to say: I get it. Those languages were some of the first I learned, and hold a charming sort of nostalgia for me as well. They are still objectively bad. We have vastly better tools now in those niches.
    - doublerabbit 2mo ago
      > We have vastly better tools now in those niches. But do we? I'll beg to differ. Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require. If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed timely manner in cron, it works just fine. The overhead of using languages compared to the previous is partly why I keep using bash or Tcl.
      - akdev1l 2mo ago
        from subprocess import run from sys import argv source = argv[1] destination = argv[2] run([ "rsync", "-zavp", source, destination ]) vs #!/usr/bin/env bash source="$1" destination="$2" rsync \ -zavp \ "$source" \ "$destination" the overhead is not really that bad imo
godelski 2mo ago
I love bash. I write a lot of bash too. It is a extremely powerful and useful language. But that also doesn't mean it is a good language. There are many non-intuitive things, hence that pitfalls page I linked. You can't just deflect and say that the user is "holding it wrong". If it is difficult and unintuitive in how to "hold" it correctly, that's a design problem, not a user problem. Despite bash being a terrible language, I still use it on a daily basis because it is useful. But don't conflate these things.

isityettime 2mo ago

`find` isn't a Bash built-in and has basically nothing to do with Bash as a language. Not knowing `find` is a basic Unix literacy issue, not a Bash language footgun. You're right that Bash is full of footguns, especially around quoting. And you're also right that that issue is even worse— and I think it's somewhat representative. Some of the cited Bash footguns are also about general lack of familiarity with CLI conventions and stringly typed data generally, like the dirname quoting issue.