On Wednesday 2021-06-02 09:40, Adam Majer wrote:
symlinks -- they only really allow a SINGLE choice to be preferred.
It so happens that any ordering of elements in a set implies that one is the first.
But, what happens when you run `node14` and then that program re-execs #!/usr/bin/node in a subprocess? The subprocess runs node16 and you are out of luck.
exec is a willfull boundary. (Just like /usr/libexec and /usr/bin.) Programs using these mechanisms _must not_ care about changes in architecture, language, memory layout, etc. nodejs's behavior sounds incredibly stupid.
I expect the same issue exists with ruby and python3 and other interpreters
python3 would hardly exec /usr/bin/python (v2). They're still sane.
The second issue that comes up is inability to actually manage preferences on a user level. Imagine you have all editors installed on a multi-user system. The user cannot specify their preferences bypass update-alternatives and resort to manual symlink hackery in ~/.bin or similar. [The plan is] moving the logic into a library. The /usr/bin/node would link to it and exec the preferred node version based on user preferences
Making /usr/bin/editor a program that painstakingly loads a ton of ELF libraries, parses config files is such a bad idea. Both export EDITOR=/usr/bin/joe alias editor='$EDITOR' export PAGER=/usr/bin/less or PATH="$HOME/bin:$PATH" ln -s /usr/bin/joe ~/bin/editor exec the "right" program, "right away" (after perhaps a search through PATH - it's still a _lot_ less syscalls).