4 ms·

This reminds me of one of the _very few_ bits of freebsd userspace that are better than gnu and was only adopted by gnu much later (8.30, the version first in d

by jepler 6y ago

This reminds me of one of the _very few_ bits of freebsd userspace that are better than gnu and was only adopted by gnu much later (8.30, the version first in debian buster, I think): `env -S`. `env -S` introduces an option parser/splitter for #!-lines which can do just about whatever you need (however, it will not work around over-long lines like sbang proposes to do)

hobby-coder-guy 6y ago
What can it do?
chrismorgan 6y ago
So, taking the example from the GNU man page: #!/usr/bin/env -S perl -w -T Why is the `/usr/bin/env -S` even in there? Why not rather #!perl -w -T I know that not all environments support non-absolute paths to interpreters like this, but it feels to me that adding -S to env is a worse hack than allowing non-absolute paths to interpreters. I’m not sure which platforms support resolving the interpreter by PATH (actually, is supporting it a shell thing?), but it may even be more portable than -S at present, GNU coreutils env only having had it for two years. And even /usr/bin/env itself isn’t fully portable, as there are (old) platforms that have env at /bin/env and not /usr/bin/env.
- tgamblin 6y ago
  It's there because on some systems all the args are passed as one. -S splits them out. You can try this on Linux and env even warns you about it: # cat test.py #!/usr/bin/python3 import sys print(sys.argv) $ cat test #!/usr/bin/env test.py foo bar baz $ PATH=. ./test /usr/bin/env: 'test.py foo bar baz': No such file or directory /usr/bin/env: use -[v]S to pass options in shebang lines with -S, env does the right thing, and you get this: $ cat test #!/usr/bin/env -S test.py foo bar baz $ PATH=. ./test ['./test.py', 'foo', 'bar', 'baz', './test']
  - chrismorgan 6y ago
    You completely missed the point of what I was writing. I’m not talking about why -S, but why /usr/bin/env -S.
    - tgamblin 6y ago
      Yeah I guess I read that too quickly -- sorry. This: #!python3 Seems to work (i.e., search $PATH) on macos but AFAIK nowhere else. It fails on both ubuntu20 and centos8. Per this: https://www.in-ulm.de/~mascheck/various/shebang/ https://www.in-ulm.de/~mascheck/various/shebang/, relative paths are supposed to be interpreted as relative to ., so I'm guessing that is why everyone uses /usr/bin/env. Given that shebang is implemented in the kernel (and not in user-space like coreutils) I think env is more likely to change than the shebang mechanism, though who knows -- there have been recent changes to shebang so perhaps further work on this will help: https://lwn.net/Articles/779997/ https://lwn.net/Articles/779997/.
      - chrismorgan 6y ago
        The shell you’re using matters, too; I find that PATH search happens when starting things from zsh, but not bash or sh. That might be why you observe it working on macOS, I dunno—they switched to zsh a while back, didn’t they? I’m not sure how much is in the kernel and how much is elsewhere, but I do observe that the shell is at least partly responsible for the error message like `bash: /path/to/script-with-shebang: python3: bad interpreter: No such file or directory`.
- deleted 6y ago
  [deleted]
- marcthe12 6y ago
  The kernel doesn't handle path variable. Userspace does.

by jepler 6y ago

hobby-coder-guy 6y ago

What can it do?

chrismorgan 6y ago

So, taking the example from the GNU man page: #!/usr/bin/env -S perl -w -T Why is the `/usr/bin/env -S` even in there? Why not rather #!perl -w -T I know that not all environments support non-absolute paths to interpreters like this, but it feels to me that adding -S to env is a worse hack than allowing non-absolute paths to interpreters. I’m not sure which platforms support resolving the interpreter by PATH (actually, is supporting it a shell thing?), but it may even be more portable than -S at present, GNU coreutils env only having had it for two years. And even /usr/bin/env itself isn’t fully portable, as there are (old) platforms that have env at /bin/env and not /usr/bin/env.

tgamblin 6y ago
It's there because on some systems all the args are passed as one. -S splits them out. You can try this on Linux and env even warns you about it: # cat test.py #!/usr/bin/python3 import sys print(sys.argv) $ cat test #!/usr/bin/env test.py foo bar baz $ PATH=. ./test /usr/bin/env: 'test.py foo bar baz': No such file or directory /usr/bin/env: use -[v]S to pass options in shebang lines with -S, env does the right thing, and you get this: $ cat test #!/usr/bin/env -S test.py foo bar baz $ PATH=. ./test ['./test.py', 'foo', 'bar', 'baz', './test']
- chrismorgan 6y ago
  You completely missed the point of what I was writing. I’m not talking about why -S, but why /usr/bin/env -S.
  - tgamblin 6y ago
    Yeah I guess I read that too quickly -- sorry. This: #!python3 Seems to work (i.e., search $PATH) on macos but AFAIK nowhere else. It fails on both ubuntu20 and centos8. Per this: https://www.in-ulm.de/~mascheck/various/shebang/ https://www.in-ulm.de/~mascheck/various/shebang/, relative paths are supposed to be interpreted as relative to ., so I'm guessing that is why everyone uses /usr/bin/env. Given that shebang is implemented in the kernel (and not in user-space like coreutils) I think env is more likely to change than the shebang mechanism, though who knows -- there have been recent changes to shebang so perhaps further work on this will help: https://lwn.net/Articles/779997/ https://lwn.net/Articles/779997/.
    - chrismorgan 6y ago
      The shell you’re using matters, too; I find that PATH search happens when starting things from zsh, but not bash or sh. That might be why you observe it working on macOS, I dunno—they switched to zsh a while back, didn’t they? I’m not sure how much is in the kernel and how much is elsewhere, but I do observe that the shell is at least partly responsible for the error message like `bash: /path/to/script-with-shebang: python3: bad interpreter: No such file or directory`.
deleted 6y ago
[deleted]
marcthe12 6y ago
The kernel doesn't handle path variable. Userspace does.