[BiteCode_dev]

Portability for shell scripts is over rated in 2022.

If your shell scripts are small, it's easy to write several versions of them.

It they are long, you should use something else than shell scripts for your program, like python.

Worse case scenario, provision the same interpretter everywhere, vendor it, or use a compiled language.

There are some edge cases where portability makes sense (e.g: you are scripting for an heterogeneous parc of routers), but they are niche usages most companies don't care about.

[mburee]

Because pulling in a huge python installation on small/embedded systems is fun, just because some people are unable to keep their scripts POSIX compliant

[BiteCode_dev]

Scripting in bash in a portable manner on embedded system is exactly the niche use cases I talked about. The router example is aimed at it, because it's the right size ratio to be small, but have an OS running.

Still, the vast majority of IT projects do not fall in that category.

It exists, but it's a very, very small % of why you need a bash script. And in fact, even those advocating for bash portability almost never fall into the category of people that have to do it in their daily job.

I'll go even further and even state that a lot of embedded system don't even have bash scripting capabilities in the first place.

[ms4720]

Tcl, lua, or a lisp/scheme work well here

[chasil]

The nice thing is that many, many shells implement POSIX, so there is enormous portability.

Busybox bundles the Almquist shell, and there is a Windows port available. This is the easiest and least intrusive way to run shell scripts on Windows.

Busybox advertises that it bundles bash, but this is not true - it's Almquist with some added bashisms.

It also bundles their own awk implementation, but not Tcl/lua/lisp/scheme.

[kaba0]

It’s not the compatibility which is the problem, but the 3 bugs/line that bash causes.

[Alupis]

If you cannot take the time to learn the language, what makes you so confident your python doesn't also have 3 bugs per line as well?

[kaba0]

Did you run shellcheck on it, to actually recognize all the errors, before you assumed it is correct?

[Alupis]

Writing bash scripts is really not that difficult - despite what folks might want to convince you of.

ShellCheck is a great tool, yes, and can be run natively inside your IDE. Just like any language, you need to learn the language and learn it's tools.

Blanket statements like "write all your scripts in python because there's less bugs" really just means the commenter is more familiar with python. Do enough script writing and you'll realize how absurd that statement is.

It's a lot like the folks that scream nobody should ever write a single line of C or C++ because it's "dangerous" - yet untold number of lines of C/C++ are written every day. A pencil can be dangerous in the wrong hands...

[Arnavion]

Yes I did. And I hope you ran mypy on yours.

BTW both shellcheck and mypy are equally optional, so I'm not sure what your high horse is about.

[BiteCode_dev]

Well I use both extensively, and I'm very confident that I can write a script of 1000 lines with much less bug and much better error handling that in bash, in half the time it would take me.

In fact, as soon as you need to use arrays, it's game over.

[RealAlexClay]

1000 lines in python is a bash oneliner and planning for failure is bad design.

>In fact, as soon as you need to use arrays, it's game over.

Why?

PS. comfortable with both. I don't draw lines based on LOC or arrays.