5 ms·

I like bash, zsh and other shell languages as well. However, unless you're really experienced, they shouldn't be the product you ship, whether that is internall

by kjuulh 3y ago

I like bash, zsh and other shell languages as well. However, unless you're really experienced, they shouldn't be the product you ship, whether that is internally or externally to you or your company. Shell languages is the final layer of configuration and customization you apply to the setup, it should almost never be the foundation of what you build. 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. The way we develop infrastructure automation, ci, and developer tools is binaries first and foremost, then plugins for our infrastructure (also binaries, or libraries) and then some zsh on top to provide a nice developer experience. But we've had to heavily scale back our use of zsh, it simply turned into a ball of mud, like all software that isn't maintainable, upgrade-able, or simple enough to parse. This isn't a dig on zsh, bash etc, we've just found out that we can't maintain zsh as a product to supply to our engineers, and as such have to correct.

nerdponx 3y ago
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.
- JNRowe 3y ago
  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-zsh_002fmapfile-Module https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...
  - nerdponx 3y ago
    I believe Bash readarray/mapfile is more like doing this in Zsh: lines=( "${(@f)$(my_command)}" ) or lines=( "${(@f)$(<my_file)}" ) which IMO is a little less nice than using a builtin with a name like "readarray". But this is cool too.
izzdrasil 3y ago
One of the best shell skills you can have is knowing when to write it in another language.
0xbadcafebee 3y ago
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.
- inferiorhuman 3y ago
  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.
  - deleted 3y ago
    [deleted]

by kjuulh 3y ago

nerdponx 3y ago

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.

JNRowe 3y ago
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-zsh_002fmapfile-Module https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...
- nerdponx 3y ago
  I believe Bash readarray/mapfile is more like doing this in Zsh: lines=( "${(@f)$(my_command)}" ) or lines=( "${(@f)$(<my_file)}" ) which IMO is a little less nice than using a builtin with a name like "readarray". But this is cool too.

izzdrasil 3y ago

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

0xbadcafebee 3y ago

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.

inferiorhuman 3y ago
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.
- deleted 3y ago
  [deleted]