Stricter POSIX sh compliance

[mcandre]

Thank you for publishing ruby-install, this really helps!

Could ruby-install be written closer to POSIX sh? It'll be tough, but the reward is better support for POSIX sh users, ksh users, and zsh users.

[havenwood]

Yes, ruby-install could be rewritten, but portable shell tends to bring bugs in various shells in the parts that go beyond what POSIX defines. With chruby, speed and preexec functions require that it run in your shell, so the hope is to be as portable as possible while still supporting the core features. With ruby-install, it's more like a regular program that just happens to be written in the language bash.

It's a fun exercise to rewrite ruby-install in another shell, but I personally wouldn't have fun trying to rewrite it without going beyond what POSIX defines. Rewriting ruby-install in ksh or zsh would be fairly easy. For example, this is my zsh script to install nightly Ruby on macOS. I think enough programs have bash as a dependency it doesn't seem like a real downside to me to have it written in bash.

Did you run into pain around bash being unavailable? Or what would be the advantage from not running in bash? The downside I see with attempting to run ruby-install portably is increasing the amount of bugs and the difficulty to maintain. I suspect efforts around portability are much better dedicated to chruby.

[mcandre]

Did you run into pain around bash being unavailable?

Yes and no. In many environments, bash is generally and easily available. There some like Alpine, BSD, Busybox, macOS Catalina, where bash is not the default shell or may even not be installed by default. So that represents some minor additional hurdles for users to be able to enjoy ruby-install.

Even where bash is available, it's awkward to have to leave your particular shell and interact with bash. zsh and ksh users would be better serviced with pure zsh and pure ksh scripts, though of course it's much easier to manage a single POSIX sh script than independent lines of zsh, ksh, and bash scripts.

[havenwood]

There some like Alpine, BSD, Busybox, macOS Catalina, where Bash is not the default shell or may even not be installed by default.

The default shell isn't really relevant to shebang commands. If a compatible version of Bash is available, the tool just works from any shell. As a dependency, Bash does need to be installed, which is a one-liner from any of the above.

Even where bash is available, it's awkward to have to leave your particular shell and interact with bash.

It's just a shebang executable command like any other on your system. Don't leave your shell. Just run the ruby-install command from your shell of choice. What are you doing that you find awkward?

[havenwood]

@mcandre Maybe try porting to sh and see if it runs nicely on the systems you mention? If we were forced to rewrite, I'd personally rather go with Rust or something less frustrating than attempting portable shell, which seems likely to me to result in lots of bugs and endless compatibility decisions.

[havenwood]

Just repeating this verbatim from a chruby thread, but as the Oil author writes, POSIX doesn't define enough common ground so shells have gone beyond it and diverged.

For bigger programs, limiting yourself to POSIX is not just inconvenient, it's also an ill-defined and virtually untestable concept...

Local variables are essential for writing maintainable shell scripts, but POSIX doesn't mention them.

This issue isn't theoretical — bash and dash differ in practice, but POSIX doesn't specify which is correct. In other words, POSIX is incomplete and out of date. (However, I've discovered that shells are highly conformant with respect to things the standard does specify.)

In other words, POSIX is incomplete and out of date. (However, I've discovered that shells are highly conformant with respect to things the standard does specify.)