Some systems have started provided ZSH for license reasons (they don't want to agree to the license of BASH).
I experimented with and found that I can make my scripts ZSH friendly.
There is no way to "detect" that ZSH is being used as far as I can tell so I defined a new environment variable SHELL_ENGINE.
Set this to "zsh" and then run the script via the "zsh" program.
Enable emulation mode of "ksh" when using ZSH to be BASH friendly.
The ZSH doesn't support "${!i}" substitution.
I found a separate way to do this in ZSH via "${(P)i}".
It is a shame that they cannot simply replace "(P)" with "!".
There are several cases where "bash" is being directly called.
Replace this with a "shell_command" environment variable.
In some cases, directly calling "bash" may cause a loss of needed environment settings and so "bash" is not directly called when using BASH but "zsh" is still directly called when using ZSH.
The ZSH does not automatically handle arrays as well as BASH does.
Explicitly define arra with "-A" and explicitly set the initial value to "()".
Doing this may introduce problems with older versions of BASH that do not support "-A".
The ZSH cannot expand parameters as intelligently as BASH.
Parameters followed by certain characters, such as a bracket, that are not encases in braces result in ZSH errors.
Mass change many of the parameter uses to always be in braces.
Not all cases are changed and there may be some areas where I intended to make such a change and missed.
The ZSH appears not to handle output redirection from shell functions.
This behavior is used heavily in the project for building and using the variables array.
Change the behavior (at the cost of making the code a bit ugglier and harder to read in some cases) to assign a variable defined at a higher scope (such as "key").
The ZSH also appears to utilize "path" as a variable for "PATH" or is case insensitive when it comes to environment variables and shell variables.
This is a serious problem.
The variable "path" is defined so rename that to "path_" to avoid conflicts (and I'll just have to suffer cringing every time I see that trailing underscore).
I stumbled onto some bugs as well while making changes.
The necessary changes change the code that is buggy so I am allowing it to be in the same commit.
One of the bugs is a typo where errror is used rather than error.
Another bug is where the c_warning is used and then c_error is used within the same string (should be consistently using c_warning in this case).
It turns out "has-build_compiler" is not defined but conveniently a space for it is missing in bootstrap.sh (must be an accidental delete given the coincidence).
Some of the "mode" properties are incorrectly being assigned the non-mode value when a mode value exists in bootstrap.sh.