[Feature] Portable Shell Script

[Lohann]

Hello, first thank you for creating this awesome language.
I think Amber could help a broader audience if it had the option to produced only Portable Shell Code, personally I was looking for some alternative to GNU autoconf which various C projects use to probe the operating system to find dependencies, test compilers, etc..
The issue with autoconf is that it adds a bunch of .m4 files to the project, and require the developer to write an ugly mix of shell with m4 macros which by the end become a single ultra portable configure shell script.
The are other alternatives to autoconf, but usually requires extra dependencies in the system or aren't portable across different systems, while a shell script works out-of-the-box "almost" anywhere and doesn't requires any other dependency in the system.

Bash is not optimal for MacOS or Windows systems

• In MacOS the default shell is zsh (or a very old bash), which have some incompatible features to bash, and other things behaves differently than bash. Apple ships a pretty old bash for compatibility purposes, but because amber produces bash code, we cannot safely do source inside .zshrc for example.
• Other targets includes Windows MSYS2 and WSL shells, etc.

While trying to get rid of autoconf I collected a few portable shell scripts examples here:
https://github.com/Lohann/shell-tools/tree/main/scripts

[Mte90]

Amber generates a valid bash 3.2 code and we are working on zsh #1000

We have already other users asking for other language transpiling like #90 but our focus is just bash, at least for now.

[Tirito6626]

while I had intentions to originally make the scripts being portable on different shells, it's rather expensive and unreliable in terms of code stability and performance

we are going another route by introducing shell target option to transpile the script into the best syntax for each shell

[Lohann]

@Mte90 @Tirito6626 thanks for the rapid reply.

I know this use case may be very specific, I understand that portability compromises performance. But for this use case specific simply adding support to zsh or other shells doesn't solve the issue as I don't control where developers are going to compile the code, could be an old docker image or machine, even if I restrict the script to work only in bash, it still may be a buggy one.

For example in most bash versions the script below outputs 5- - -
But due a bug in bash 4.1 this same script outputs 3- - -

bash -c 'n() { echo "$#$@"; }; f="  -  "; n - ""$f"" -'

It may cause an unrelated error elsewhere in the script, impossible to reproduce if not using that exact version, plus usually first we assume the issue is in some program, environment variable or system dependency, not in the shell.

Some bash and dash versions don't understand the regular expression operator +, so instead of doing ^[<pattern_here>]+ I must do instead ^[<pattern_here>][<pattern_here>]*.

Keeping tracking of those subtle exceptions is super annoying, ignoring it is also a source of headache as developers may be trying to compile the code in one of those buggy shells, and will open an issue impossible to reproduce and debug. That's why even being super old and ugly, we are forced to use GNU autoconf because there's no other alternative available.

[Mte90]

Ideally for this bug in bash we should try to create an amber example so we can add a tests for it as we have a CI for any bash version to run our tests.

And yes, it is annoying track all of them but with our CI we can see if Amber can do a workaround for this case.

I understand your point and with Amber we are trying to do our best to support everything but as you can see we don't have so many contributors to work on everything.

[Lohann]

I understand your point and with Amber we are trying to do our best to support everything but as you can see we don't have so many contributors to work on everything.

Good because I can help, I played a bit with heraclitus while checking how hard would be modify amber to generate posix portable code, I already had some work grabbing portable shell code in this repo, my availability is limited this week but I'll give it try in my free time, the dream is be able to write automation scripts using a mordem typed checked language that outputs portable shell code, then finally free developers from autoconf, python, meson tyranny once for all.

[Mte90]

Cool :-)

If we improve first the syntax and the compiler itself we can focus on other languages in the future but we need to build the core first.

[Tirito6626]

i think it's also worth considering adding supported shell metadata/something to tell the compiler which versions/shells are supposed to work with the following script, probably with something like macro which we are planning to add anyways