Hacker News Reader

Comment by sebstefan | Hacker News Reader

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

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.

View on HN

> I have this web page saved up in case I ever need to convince anyone of this... 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.

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

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

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)

> I don't trust myself so I need my language to not be bug-prone

Which language is that?

Do you write unit tests in other languages? Do you write unit tests for your bash scripts?

Yes, if the "script" is big enough. I use BATS for that.

Shellcheck is amazing at preventing bugs!

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.

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.

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

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.

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.

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.

Powershell passes data not instructions and a lot of those complaints sound like trying to write another language in Powershell. I've shoved json from node through Powershell into the clipboard and back to filter with select-object and out. the situation making you invoke bat at all is what MS ruined and that's not Powershell fault.

It's not me deciding to mix bat and powershell, and it's not niche:

https://github.com/search?q=powershell+language%3ABatchfile&...

There's a need for a fast, nimble glue that powershell can't deliver on its own.

This is what I meant, these are all examples working around the default execution policy. That's microsoft ruining things not powershell as a language. I didn't say it was niche rare or wrong. It's just bad and it's MS's fault.

Technically it's Windows' "here's a string of the commandline, go parse it yourself" (vs. argv array) that's the issue as every program can interpret quoting, escaping etc. differently. All these programs being from MS (powershell, cmd) does make them a little guiltier I guess.

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.

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.

Reply on news.ycombinator.com