I find such reasoning backwards. Indeed, shell scripting is not friendly to debugging. But ensuring correctness of shell scripts is essential: usually, they touch part of your "$HOME" or system folders and do tons of I/O, some of it destructive. I find it baffling to see people write careless scripts; sometimes using `rm` for cleanup with unquoted parameters, or much worse, dangerous uses of `mv`.

I believe OP's point was that any shell script complex enough to require debugging should not be a shell script any more.

I believe P's point was that it doesn't matter how simple or complex a script (or anything else) is, everything requires debugging. And/or that you have to be ready to debug bash regardless if you like it or not, regardless what you choose to write your own stuff in.

OP's comment is not unfunny and not 100% untrue either though. But not 100% true either. A single word script still needs to be debugged.

> And/or that you have to be ready to debug bash regardless if you like it or not, regardless what you choose to write your own stuff in.

Over a decade into my career, and I've successfully managed to avoid debugging Bash scripts.

There is hope for people who don't want to.

I hear this argument occasionally and it’s very contextual. While it’s certainly possible to rewrite any given shell script in Python, Rust, or whatever language you prefer there are some things which are just clearer in Bash.

I wouldn’t want to write an entire application in Bash, but equally I wouldn’t want to write a script which does relatively simple file operations in Python. Bash is a language which has been honed over many decades for precisely that sort of thing, and so can communicate what’s happening far clearer than Python does in my view.

While that's certainly true for people trying to do very complex things in "pure" shell, when the tools you're using are possibly buggy, it's not very useful. Sometimes you have to debug and figure out where the problem is occurring, an then you can do the much simpler work of replacing one part rather than writing a bespoke program to replace all the boring functionality obfuscated away by shell and the working programs.

Doesn't make sense. What if you get a script someone else wrote? Printing every command and confirming as you run every command is a great idea.

And, unfortunately shell has become the norm in CI/CD environments, pipelines etc. Can be convenient at times but can also be inconvenient and confusing as these scripts don't run in interactive shells.

> And, unfortunately shell has become the norm in CI/CD environments, pipelines etc.

A pipeline which relies on shell is not worth using, tbh. That's how much shell sucks.

What language would you base a pipeline on?

I agree that bash sucks, but have yet to find anything to replace it that doesn't increase complexity and version problems.