5 ms·

I've done a lot of Bash, read some books about it, I'm a firm believer that nobody should be writing anything complex in bash. Above the ballpark of 50 lines I

I've done a lot of Bash, read some books about it, I'm a firm believer that nobody should be writing anything complex in bash. Above the ballpark of 50 lines I consider it a code smell. I have this web page saved up in case I ever need to convince anyone of this. http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls I used Powershell recently and not having to wrangle with text (commands return objects) makes it a much easier scripting language, and command line language. The fact that they have an official way to handle argument parsing is excellent, everything is unified and the commandline window is able to have autocompletion for literally every option of everything. Bash could never even dream of having that. It is incredible and makes you extremely productive. But type coercion manages to introduce new ways to create bugs that Bash didn't have. Honestly at this point I prefer PWSH but still kinda dislike both. I'm waiting for the new natural evolution.

sebstefan 2y ago
I forgot but one thing I also liked that made me go "Why would bash not have that?" is having a dedicated verbose,info,warn,error,debug output and a glob star *> to redirect everything. It's nice not having verbose text polluting stderr.
PeterWhittaker 2y ago
> I have this web page saved up in case I ever need to convince anyone of this... http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls This is a great list of pitfalls, absolutely, but they are more an argument for integrating shellcheck into your IDE than avoiding bash, IMHO! I know, I know, possible religious war, but I find that bash+shellcheck is far more often the right toolset than switching languages to avoid the pitfalls. The immense power and expressiveness and immediacy of bash makes so many programs and so much prototype->PoC->MVP progression so easy and effortless that it is worthwhile having tooling to catch the worst of the warts.
- jonhohle 2y ago
  Add shunit or similar and I You can have a really nice experience (imho).
alganet 2y ago
Many of these pitfalls are not the shell, but external programs (sed, xargs, grep, etc). I know it ends up in the same terminology bucket for the public consciousness as "CLI stuff", but there is a separation and understanding this separation is crucial for writing good sh. The problem actually lies in bash+coreutils being some sort of de-facto standard for command line stuff. The way bash+coreutils evolved was mostly for autotools and not for humans. This ecosystem could be much better. PowerShell has more builtins, so it relies less on external commands, therefore it is less vulnerable to pitfalls due to mismatches between different programs.
- sebstefan 2y ago
  For mismatches, custom scripts & commands in Powershell benefit from having a standard way to take input, and because the output is not text, you're also safer on that end But in the end really it doesn't matter in whose end of the kingdom the bugs come from. What matters is that's how people write Bash.
  - alganet 2y ago
    It works very well if you're all inside powershell. Try this exercise: make a .BAT invoke a powershell script that invokes another .BAT passing parameters containing double quotes inside. It just can't be done reliably. The .BAT is only just an example, any param passing to/from powershell (outside powershells internals) is a nightmare. In bash, this kind of interaction is commonplace. You can make `find` generate shell snippets for you, and pipe the generate shell commands into another interpreter instance seamlessly. Think of the sheer amount of software the uses the shell this way and you never notice. That npm script that just passes parameters along is relying on the shell interface, that CI yaml that passes variables is relying on the the shell interface, etc. It runs just for a few milliseconds, to pass and glue things around, super simple. Powershell is just not designed nor suitable for that. The problem of an uniform interface _can_ be solved by changing how people write stuff. The problem of not fitting well as an architectural piece replacement is much more difficult to overcome. Powershell fits Windows though, but that's about it.
nunez 2y ago
I don't know if I agree with that. I write Bash; I've written some stuff I really shouldn't have written in Bash. Writing elegant Bash is possible, though I agree it is very easy to footgun yourself with it. The problem is that Bash is right at the middle of "I need something quick" vs "I don't want to break out Golang or whatever" and Bash is installed damn nearly everywhere. A 50-line awk script though? Get outta here with that lol
- sebstefan 2y ago
  I don't trust myself so I need my language to not be bug-prone (and I don't recommend it for others because if we're looking at it realistically, most people who trust themselves shouldn't trust themselves)
  - candiddevmike 2y ago
    > I don't trust myself so I need my language to not be bug-prone Which language is that?
  - jonhohle 2y ago
    Do you write unit tests in other languages? Do you write unit tests for your bash scripts?
    - nunez 2y ago
      Yes, if the "script" is big enough. I use BATS for that.
  - nunez 2y ago
    Shellcheck is amazing at preventing bugs!
- Already__Taken 2y ago
  it just isn't everywhere though. sh, ash zsh, Mac... windows are all different. you think it works everywhere but really its just breaking and nobody is telling you. python is just as everywhere and that's a total mess.
inquist 2y ago
I’ve spent so much time wrestling with and learning all (most) of these pitfalls, and I consider it time well spent. After my first few weeks I started dreaming in bash.
bigstrat2003 2y ago
I totally agree. Bash is an absolute nightmare to program in. Just an utter mess of a language, one which I avoid if at all possible. Whereas powershell is an actual sensible language. I love writing it, and honestly I wish it was popular enough in *nix land that I could feasibly use it there too.
- logicprog 2y ago
  Well, there's nushell, which probably integrates better with *nix than pwsh, although it isn't popular either

sebstefan 2y ago

I forgot but one thing I also liked that made me go "Why would bash not have that?" is having a dedicated verbose,info,warn,error,debug output and a glob star *> to redirect everything. It's nice not having verbose text polluting stderr.

PeterWhittaker 2y ago

> I have this web page saved up in case I ever need to convince anyone of this... http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls This is a great list of pitfalls, absolutely, but they are more an argument for integrating shellcheck into your IDE than avoiding bash, IMHO! I know, I know, possible religious war, but I find that bash+shellcheck is far more often the right toolset than switching languages to avoid the pitfalls. The immense power and expressiveness and immediacy of bash makes so many programs and so much prototype->PoC->MVP progression so easy and effortless that it is worthwhile having tooling to catch the worst of the warts.

jonhohle 2y ago
Add shunit or similar and I You can have a really nice experience (imho).

alganet 2y ago

Many of these pitfalls are not the shell, but external programs (sed, xargs, grep, etc). I know it ends up in the same terminology bucket for the public consciousness as "CLI stuff", but there is a separation and understanding this separation is crucial for writing good sh. The problem actually lies in bash+coreutils being some sort of de-facto standard for command line stuff. The way bash+coreutils evolved was mostly for autotools and not for humans. This ecosystem could be much better. PowerShell has more builtins, so it relies less on external commands, therefore it is less vulnerable to pitfalls due to mismatches between different programs.

sebstefan 2y ago
For mismatches, custom scripts & commands in Powershell benefit from having a standard way to take input, and because the output is not text, you're also safer on that end But in the end really it doesn't matter in whose end of the kingdom the bugs come from. What matters is that's how people write Bash.
- alganet 2y ago
  It works very well if you're all inside powershell. Try this exercise: make a .BAT invoke a powershell script that invokes another .BAT passing parameters containing double quotes inside. It just can't be done reliably. The .BAT is only just an example, any param passing to/from powershell (outside powershells internals) is a nightmare. In bash, this kind of interaction is commonplace. You can make `find` generate shell snippets for you, and pipe the generate shell commands into another interpreter instance seamlessly. Think of the sheer amount of software the uses the shell this way and you never notice. That npm script that just passes parameters along is relying on the shell interface, that CI yaml that passes variables is relying on the the shell interface, etc. It runs just for a few milliseconds, to pass and glue things around, super simple. Powershell is just not designed nor suitable for that. The problem of an uniform interface _can_ be solved by changing how people write stuff. The problem of not fitting well as an architectural piece replacement is much more difficult to overcome. Powershell fits Windows though, but that's about it.

nunez 2y ago

I don't know if I agree with that. I write Bash; I've written some stuff I really shouldn't have written in Bash. Writing elegant Bash is possible, though I agree it is very easy to footgun yourself with it. The problem is that Bash is right at the middle of "I need something quick" vs "I don't want to break out Golang or whatever" and Bash is installed damn nearly everywhere. A 50-line awk script though? Get outta here with that lol

sebstefan 2y ago
I don't trust myself so I need my language to not be bug-prone (and I don't recommend it for others because if we're looking at it realistically, most people who trust themselves shouldn't trust themselves)
- candiddevmike 2y ago
  > I don't trust myself so I need my language to not be bug-prone Which language is that?
- jonhohle 2y ago
  Do you write unit tests in other languages? Do you write unit tests for your bash scripts?
  - nunez 2y ago
    Yes, if the "script" is big enough. I use BATS for that.
- nunez 2y ago
  Shellcheck is amazing at preventing bugs!
Already__Taken 2y ago
it just isn't everywhere though. sh, ash zsh, Mac... windows are all different. you think it works everywhere but really its just breaking and nobody is telling you. python is just as everywhere and that's a total mess.

inquist 2y ago

I’ve spent so much time wrestling with and learning all (most) of these pitfalls, and I consider it time well spent. After my first few weeks I started dreaming in bash.

bigstrat2003 2y ago

I totally agree. Bash is an absolute nightmare to program in. Just an utter mess of a language, one which I avoid if at all possible. Whereas powershell is an actual sensible language. I love writing it, and honestly I wish it was popular enough in *nix land that I could feasibly use it there too.

logicprog 2y ago
Well, there's nushell, which probably integrates better with *nix than pwsh, although it isn't popular either