3 ms·

It's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executa

by jolmg 9y ago

It's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executable path, and if there's a space, then the rest of the line (including any additional spaces) is interpreted as 1 argument to the executable. EDIT: -e causes bash to exit on the first command that returns with an error (returns with a non-zero return code). It's documented in `man bash` where it documents the `set` builtin command.

jessaustin 9y ago
Thanks for clarifying. In that case, one could imagine an env capable of parsing its single argument into the multiple intended arguments? I admit that I never dreamed that the "set" builtin would have the information about "bash -e" while the initial "OPTIONS" section did not. Why not look under the "cd", "echo", "fc", "read", or "ulimit" builtins? Somewhat helpfully, the "COMMAND EXECUTION ENVIRONMENT" section talks about how "-e" is inherited but not what it means. Ah, man pages.
- jolmg 9y ago
  Well, to be fair, the first sentence in OPTIONS is: > All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked. It's easy to miss though, when one's accustomed to quickly searching with "/". EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It may be that there's some systems where it only takes non-whitespace characters as the first argument and drops everything else after encountering another space. There might be also other limitations that one should consider when making more use of shebangs, like the character limit of the lines. For example, I think linux only takes the first 127 characters of the shebang and ignores everything else; other systems might take less. I encountered that limit when writing this answer: https://unix.stackexchange.com/questions/365436/choose-interpreter-after-script-start-e-g-if-else-inside-hashbang/365751#365751 https://unix.stackexchange.com/questions/365436/choose-inter... EDIT 2: If you were to do such a program, it will probably also need to implement quoting and escaping syntax. The difficult part is that, since it wouldn't be a standard program to have, it'd have to be listed as a dependency of whatever projects you use it in, and I wonder if the benefit really outweighs the cost of having yet another dependency. I can't see something like this gaining wide adoption.
  - jessaustin 9y ago
    Haha thanks that is why I missed it.
JdeBP 9y ago
Interestingly, FreeBSD used to allow for multiple arguments.
- jolmg 9y ago
  Do you know why they stopped?
  - JdeBP 9y ago
    https://svnweb.freebsd.org/base?view=revision&revision=146731 https://svnweb.freebsd.org/base?view=revision&revision=14673...
    - jolmg 9y ago
      So they did it for compatibility. In the end, it seems better to take everything as 1 argument instead of simply splitting on spaces, without having support for quoting and escaping. That way you can have arbitrary code with spaces in the shebang if that's ever a good idea.
      - jessaustin 9y ago
        It is probably silly to dream that kernels will change their behavior, if FreeBSD had to revert such an improvement. However as you describe env is actually downstream of the kernel, so if it were improved we could envision shebangs like the following: #!/usr/bin/env --new-env-behavior-parse-all-args=bash -e Some people might prefer a less verbose flag, but perhaps making it extra-yucky would improve adoption?

by jolmg 9y ago

jessaustin 9y ago

Thanks for clarifying. In that case, one could imagine an env capable of parsing its single argument into the multiple intended arguments? I admit that I never dreamed that the "set" builtin would have the information about "bash -e" while the initial "OPTIONS" section did not. Why not look under the "cd", "echo", "fc", "read", or "ulimit" builtins? Somewhat helpfully, the "COMMAND EXECUTION ENVIRONMENT" section talks about how "-e" is inherited but not what it means. Ah, man pages.

jolmg 9y ago
Well, to be fair, the first sentence in OPTIONS is: > All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked. It's easy to miss though, when one's accustomed to quickly searching with "/". EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It may be that there's some systems where it only takes non-whitespace characters as the first argument and drops everything else after encountering another space. There might be also other limitations that one should consider when making more use of shebangs, like the character limit of the lines. For example, I think linux only takes the first 127 characters of the shebang and ignores everything else; other systems might take less. I encountered that limit when writing this answer: https://unix.stackexchange.com/questions/365436/choose-interpreter-after-script-start-e-g-if-else-inside-hashbang/365751#365751 https://unix.stackexchange.com/questions/365436/choose-inter... EDIT 2: If you were to do such a program, it will probably also need to implement quoting and escaping syntax. The difficult part is that, since it wouldn't be a standard program to have, it'd have to be listed as a dependency of whatever projects you use it in, and I wonder if the benefit really outweighs the cost of having yet another dependency. I can't see something like this gaining wide adoption.
- jessaustin 9y ago
  Haha thanks that is why I missed it.

JdeBP 9y ago

Interestingly, FreeBSD used to allow for multiple arguments.

jolmg 9y ago
Do you know why they stopped?
- JdeBP 9y ago
  https://svnweb.freebsd.org/base?view=revision&revision=146731 https://svnweb.freebsd.org/base?view=revision&revision=14673...
  - jolmg 9y ago
    So they did it for compatibility. In the end, it seems better to take everything as 1 argument instead of simply splitting on spaces, without having support for quoting and escaping. That way you can have arbitrary code with spaces in the shebang if that's ever a good idea.
    - jessaustin 9y ago
      It is probably silly to dream that kernels will change their behavior, if FreeBSD had to revert such an improvement. However as you describe env is actually downstream of the kernel, so if it were improved we could envision shebangs like the following: #!/usr/bin/env --new-env-behavior-parse-all-args=bash -e Some people might prefer a less verbose flag, but perhaps making it extra-yucky would improve adoption?