At least you've discovered Zsh and hopefully its significant improvements over Bash. The only Bash benefit is readarray/mapfile, Z Shell is better in just about every other way.

Unless I'm misreading your comment, zsh does provide similar functionality via zsh/mapfile¹. It, and a lot of other cool stuff, is documented in zshmodules(1).

¹ https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...

* * *

One of the best shell skills you can have is knowing when to write it in another language.

Most commercial products that include an installer on *NIX are written in shell. No other method allows you to have a universal installer on every platform that will always work.

> Especially for a company, unless you've got really, really skilled engineers on the scripts, it becomes a complete mess. And even then it can become almost impossible to grok.

Dude. It's really not that hard a language. Is amateur shell script ugly? verbose? redundant? bug-riddled? Absolutely. But it works despite that, and has fewer dependencies than other solutions, so in practice, it's fine.

That said, use whatever you know. Wanna use Python? Use it. Wanna use a compiled language? Do it. Just make something. The biggest difficulties you will have in producing a product will not be the language.

You don't have to avoid shell just because people on HN (who've probably never read the man page) keep repeating that it's terrible. With Shellcheck, almost anyone can write good scripts now. If you can write a concise, bug-free script that works, then do it.

  No other method allows you to have a universal installer on every
  platform that will always work.

No shell will guarantee that either. Last week I spent a few hours debugging an installer (bash script) that was failing with a rather puzzling error message (variable not defined). Non-Linux, bash 5.x. Worked on nearly everything under the sun including OSX with its ancient GPLv2 bash.

Turns out on one non-Linux operating systems, one of the utilities used for string manipulation, while POSIX compliant, behaved differently than the same utility in nearly every other operating system.

   has fewer dependencies than other solutions

Wrong, wrong, wrong. Nearly everything you do in a shell script is an external dependency. And that's the biggest problem with shell scripts. The actual language is so narrowly scoped that you're dependent upon external utilities that are not so easy to upgrade.

Count how many programs are in /bin. Those are your dependencies. Unlike e.g. python or ruby dependencies, you'll have a much harder time upgrading /bin. Having to fork a new process for trivial tasks is also one of the reasons why shell scripts are so slow.

Sure, bash has builtin versions of some of those utilities like [, but not every system has bash.

This seems to be a general problem for what I normally refer to orchestration software. I.e. calling a lot of external dependencies, io and in general very slim on business logic. You've simply got to deal with too many dependencies, which may or may not have different versions, flavors and whatnot. It becomes impossible to test every permutation, so instead you rely on brute force to weed out bugs, simply fix the things once a bug report comes in.

It helps having good integration/e2e tests, but they only go so far, customers/developers customize and mess up their systems all the time.

Which is why I've choose binaries instead, they are mostly self-contained (except for various things about gnu and musl), and in general just rely on a higher level of built in functionality (because of the statically linked nature).

It is probably the closest we're gonna get to a universal language, until we get wasm deeper in the os' or something. It is kind of the javascript of operating systems, which is both good and bad.

It is also quite bad that we've got to vet bash installation scripts before running them, as you may be required to run them as root. IMO, this isn't a huge issue for me personally, as we already are doing this for a lot of stuff, homebrew, linux package managers etc. We generally run a lot of untrusted code on our machines.

> Dude. It's really not that hard a language. Is amateur shell script ugly? verbose? redundant? bug-riddled? Absolutely. But it works despite that, and has fewer dependencies than other solutions, so in practice, it's fine.

Bash, zsh whatever, depend heavily on what is installed on the os, and what type of flavor of base tools are provided. Need base64 in a certain way, don't forget that line wrapping is different between bsd and linux. (a pain in the butt to test too).

Need to download something, better hope you're not running on a busybox or something with curl, or only have wget installed, now you gotta build support for both.

A lot of scripts, especially installation scripts are a product of blood, sweat and tears, mostly tears tho. Each line can be interpreted in a multitude of ways, under different conditions and versions of bash, os and so on, and the script will have to be robust enough for that.

> That said, use whatever you know. Wanna use Python? Use it. Wanna use a compiled language? Do it. Just make something. The biggest difficulties you will have in producing a product will not be the language.

It may not be the biggest difficulty, but it certainly is something we should consider. We've chosen our values, and shell scripts doesn't align with those, I'd rather not fight my environment every step of our development journey.

I am not building a new product, I am maintaining and expanding a product, as such I am heavily biased towards getting as few support tickets as humanly possible, while building an awesome experience. We are also mostly software engineers, and not sysadmins, as such we prefer compiled binaries. We then choose to distribute them through curated and secure channels.

We get the benefit that we can actually test parts of our tools in isolation, benchmark them if necessary, and version our stuff in a nice concise way. If I want to run our onboarding installation, I can simply fetch our current list of binaries expected for developers and run it, because I know they don't depend on external tools from the environment. This is a lot of work, but in a large development organization, this means a lot.

> You don't have to avoid shell just because people on HN (who've probably never read the man page) keep repeating that it's terrible. With Shellcheck, almost anyone can write good scripts now. If you can write a concise, bug-free script that works, then do it.

Just to reiterate, I am not digging on shell scripts, and I don't necessarily think they're terrible, they have their time and place, and for us, it is customization and extensibility. We setup our tools such that they work awesome on the cli, and can be composed however, developers like, but that is up to them, and how they want to form their workflows.

We've seen that developers really struggle to maintain what was previously built (myself included), so now we've got a more homogeneous tech stack, which comes with its own trade offs, but whose values align more with our engineering culture.