Hacker News new | ask | show | jobs
by thayne 1399 days ago
If you have over a thousand lines of bash (or any other kind of shell code really), that is a pretty big red flag that you probably shouldn't be using bash IMO.
3 comments

If you want to issue a certificate in an environment where you only have a shell, it's the only language you can use.

Sometimes you write in shell because it's the lowest common denominator.

Well, if you have to use shell that's one thing, but I would be hesitant to use such a large shell script for something as important as certificate issuance in an environment where I didn't have to.
Just as a counter point, I've been using acme.sh for ~3 years now and it's been rock solid.

I get your point, and was pretty shocked to find acme.sh, but after the certbot PPA made a giant mess of my system I gave it a try. On the other hand, why should I balk at running thousands of lines of bash, but be fine with thousands (or many more) lines of C, Python, PERL...? You can write crappy or beautiful code in any language...

Stop bashing on bash.

It has limitations, and quoting takes a hot minute to grok, but those don't come into play for a surprising amount of medium-large projects when used properly.

I use POSIX sh only and get by with maintainability and handling failure modes just fine.

Bash is great for cases where you are gluing together a bunch of other commands. But it also has a lot of pitfalls, that something as large and complex as this will absolutely run into (to be fair, so does c).

As a specific example, the ACME protocol requires working with json. Doing this in bash is very difficult and error prone, especially if you want to avoid a dependency on something like jq, as this does.

ShellCheck and unofficial strict mode make bash a pretty nice language.
On the otherhand, if you're a user and not a developer, you know something written in bash will be written to run on any machine out there. Doesn't matter if it's old or new. Whereas if it's written in C++xx or Rust or the like it'll only compile/run on rolling release distros (or for the 3 months after a normal distro is released that it's up to date).
It might only compile on a machine with a recent compiler if it’s aggressive with using new language features, but why would need to compile a Rust/C++ version from source? A compiler binary will run jut fine on old distro versions.
On old distros you need to install the latest libc and libstdc++/libc++ to run them. I’ve tried many times in the past and never succeeded.
Typically projects will compile the binaries on systems with a much older version of libc (but the latest compiler) specifically to avoid this problem.

If they’re not doing this then I believe they won’t work on older systems even if compiled with old compiler versions.

Bash isn’t on non-UNIX machines by default. I could run a C or Rust produced binary just fine, but I couldn’t run that shell script.