Preferences: Don't rely on shebangs to launch#1920
Conversation
Since launching JS modules via shebangs relies on features of the /usr/bin/env utility that aren't universally available, avoid it where possible. The `gsconnect-preferences` "executable" (actually a JS module with a shebang line) is renamed to `gsconnect-preferences.js`, and both `prefs.js` and `daemon.js` will launch it by running `gjs -m gsconnect-preferences.js` with the extension root dir as the working directory, using `Gio.SubprocessLauncher`. A small replacement `gsconnect-preferences` shell script is provided to replace the old launcher, and tries to do the right thing with working directories. However, it should not be relied on too heavily. Partially addresses: GSConnect#1879 (only prefs, not daemon.js)
| @@ -1,104 +1,19 @@ | |||
| #!/usr/bin/env -S gjs -m | |||
| #!/usr/bin/sh | |||
There was a problem hiding this comment.
I don't think that's guaranteed to exist at that path.
...is what I wanted to write, and then I made the mistake of going to actually look at what POSIX says, and now I'm just sad.
There was a problem hiding this comment.
JFC. 😵💫
I probably should use /bin/sh, to future-proof against /usr consolidation. I'm pretty sure that's "guaranteed" to exist on any system we'd encounter in the wild -- even distros that don't use Bourne as their shell have a link from /bin/sh to dash or busybox or whatever.
The only POSSIBLE exception I can imagine might be Nix.
There was a problem hiding this comment.
On my Ubuntu system here both /bin/sh and /usr/bin/sh are symlinks to dash. I once set my login shell to /usr/bin/bash on a /usr merged Arch years ago and couldn't log in after that because /bin/bash was the canonical name even though both could execute it. I'd guess /bin/sh is perhaps slightly more safe.
I think an executable file with no shebang will get passed to sh https://utcc.utoronto.ca/~cks/space/blog/unix/EmptyFileWhyTrue, but that's also quite a silly way to do it, and then we'd perhaps need to have a non-shebang ya rly comment stating what we are doing.
|
I think the issue reference should be #1897 with the last two numbers flipped. |
daniellandau
left a comment
daniellandau
left a comment
There was a problem hiding this comment.
This was left hanging, but I don't see a reason why it couldn't go in now
2 participants
Since launching JS modules via shebangs relies on features of the /usr/bin/env utility that aren't universally available, avoid it where possible.
The
gsconnect-preferences"executable" (actually a JS module with a shebang line) is renamed togsconnect-preferences.js, and bothprefs.jsanddaemon.jswill launch it by runninggjs -m gsconnect-preferences.jswith the extension root dir as the working directory, usingGio.SubprocessLauncher.A small replacement
gsconnect-preferencesshell script is provided to replace the old launcher, and tries to do the right thing with working directories. However, it should not be relied on too heavily.Partially addresses: #1879 (only prefs, not daemon.js)