Created attachment 866697 [details, diff] Patch Having `/usr/bin/env ruby` as shebang allows the system-installed exe to be executed by user-installed Ruby which will fail unless the user-installed Ruby and its gems are compatible with the exe. The exe is system-installed and it shouldn't be affected by user setups. Shadowing executables is a problem the user Ruby's installer should care about; not the system. The exe should always run properly and run using its correct system-installed dependencies when its stub in /usr/bin is called no matter what. If there maybe stubs that have to be generic, it's the ones installed by the user Ruby's installer.
I don't think we want to lose the ability to override it by PATH.
> I don't think we want to lose the ability to override it by PATH. That's inconsistent because you won't be able to anyway if there are at least two implementations installed.
Sorry it's the other way around. If there's only one implementation, shebang should be like /usr/bin/ruby31, and in that case PATH isn't useful. Also it still doesn't make sense. Why would you want a system-installed stub to be flexible? It should always just call the ones it was installed for. Even in prefix mode it doesn't make sense. You wouldn't need to use the previous non-prefixed gems.
I just created "rubyexec", a wrapper written in C: https://github.com/konsolebox/rubyexec/blob/master/rubyexec.c This makes it even more certain a bin application only runs with its target Ruby implementations. Example shebang usage in stub: #!/usr/bin/rubyexec ruby31,ruby30 Wouldn't matter how many implementations are around. It wouldn't allow the application to execute if /usr/bin/ruby points to an implementation the application doesn't support, and instead pick the first available implementation from the comma-separated list.
