† The qualifying clause is probably unnecessary here.
I prefer bash/zsh/etc because of the ecosystem around them. If I wanted to throw that away and start from a different base I'd probably use Powershell or something like it to be honest.
I've gone back to bash, might try out zsh.
IMO its real benefit is in its scripting language, which is mostly a Bash superset with really nice quality-of-life features, namely a vast set of parameter expansion flags, super-advanced globbing options, native support for numerical-indexed arrays, and... it doesn't split arrays on whitespace unless you explicitly ask it to! You can freely iterate over filenames with whitespace, special characters, etc., and you technically don't need to quote any of it. A good Zsh programmer will be able to almost totally grep, awk, bc, etc., and all the overhead of spawning a subshell.
Some people are better at this kind of thing than me, but I find it hard when languages are close in notation (I never confuse C++ and python, but I confuse python/ruby, or bash/fish).
The dtksh binary bundled Motif X/Windows support, and scripts could easily and quickly build complex GUI applications. This actually remains the fastest and least resource intensive way to build a quick GUI.
The dtksh was written at Novell by Pendergrast, who wrote a textbook on it.
Modern ksh93 should make this a supported compile option.
I started using ksh on AIX and it has been my favorite shell since then. I've written a few thousand SLOC worth of utilities and customization scripts in KornShell.
-Floating point math, not just integer
-Coprocess syntax that is correct and compliant
-Genuine Korn retains variables in control structures
-Lots more, detailed in the Korn & Bolsky ksh93 book
The language specification for ksh93 is large and powerful, and bash doesn't approach it.
cat file |\
while read stuff
do other stuff; set variable
In my experience replacing the build system and doing nothing else is usually a good indicator for a project that will be soon abandoned. If that's the first priority it means there's no real drive to implement anything new.
Have you actually tried the legacy build system before making that comment ? If not, I would suggest you to try that. It's by far the worst build system I ever dealt with. Just to give you an example, if there's a compilation failure in the middle of build process, build system will not stop, it will continue to compile everything that it should not compile and then exit with status 0. There was an absolute need to replace it with something newer.
Replacing the build system is just the first step towards improving the code base and it's not the end of it.
To the remark about build system, I would like to offer some speculation: I have (or had?) worked with its maintainer Kurtis by way of common employer on a few projects. He is a fantastic engineer and extremely careful and diligent; from that, I would grant significant deference. His team maintained one of the most sprawling pieces of legacy shell script infrastructure I have seen in my career.
Here's to hoping for a blossoming revival of the original essentials.