Remove shebang support

[hryx]

Related:

• instead of run subcommand, treat first positional argument as the zig run target #1505
• zig fmt does not handle shebang lines #1546

---

Currently the tokenizer allows and skips over a shebang (e.g. #!/usr/bin/env zig) at the start of a source file. This feature is not documented nor is it part of the grammar.

I think the language should either explicitly support this feature or not support it at all. Right now it's kind of in a hazy middle ground.

Pros:

• Removes logic from tokenizer, formatter, and any syntax highlighters
• Acting sooner means nobody will come to depend on the feature

Cons:

• There may be a legitimate use case for the feature — I'd love to get some input from others on this

Counterarguments:

• It could be argued that this is a feature of the compiler implementation and not the language itself. But if the language docs specify source file encoding then I'm inclined to believe this is in scope as well.

[andrewrk]

I have to say my opinion on this has changed over time. I would be in favor of accepting this and rejecting #1505. Reasoning:

• Relying on system zig goes against one of the fundamental things Zig is trying to accomplish: reliable, consistent build environments, which are to some degree insulated from the differences in various systems.
• We want source code to be able to specify the version of zig it depends on, potentially allowing the zig language to make backwards incompatible changes without actually breaking code.
• We want source code to be able to depend on packages.
• The use cases of shebang lines that I can think of are:
  • distributing software
    • zig software will be better distributed through the zig package manager or system package managers
  • installed program executables
    • zig program binaries would be better installed as release-fast, release-safe, or release-small binaries
  • quick 'n dirty user scripts
    • if the main script is zig code, use zig run.
    • otherwise, I could see how shebang lines might be handy for this use case. I'll note, however that for this use case it would be reasonable to hard code the full path to a specific zig version with run as the parameter, and so still instead of run subcommand, treat first positional argument as the zig run target #1505 would not be needed. I will also note that a quick 'n dirty user script could make a shell script that simply executed zig run ....

So with all this in mind, I would accept the fact that one use case would be a little bit more trouble, but zig project becomes just a little bit simpler.

That said, I am also open to input on this.

[daurnimator]

I think that shebang support is a great feature for not only quick n dirty scripts but getting started with the language and teaching. Being able to share a script with someone and say "just chmod +x it and run it" is hugely beneficial to getting people into the language.

Relying on system zig goes against one of the fundamental things Zig is trying to accomplish: reliable, consistent build environments, which are to some degree insulated from the differences in various systems.

It doesn't rely on system zig though: it relies on the zig in your PATH. Which may be system zig; or it may be an old version, or any version...

We want source code to be able to specify the version of zig it depends on, potentially allowing the zig language to make backwards incompatible changes without actually breaking code.

Yes we should! We probably want some annotation that says "written and tested against zig versions X, Y, Z". I don't see it as very related to this issue though.

We want source code to be able to depend on packages.

Yes.... again, not sure how this is related. If I @import("foo"), then I should have a library "foo" available somewhere in my zig library search path. Otherwise there should be a reasonable error, telling you to either fix your search path or install the package (either locally or system wide: user's choice)

[tgschultz]

"just chmod +x it and run it"

If you're already having to run chmod on it, and relying on a zig being in the PATH, then why not just say "run zig run on it"? It's not like this feature buys you the ability to distribute "zig scripts" to just anybody and and have a reasonable assurance they'll work.

[daurnimator]

already having to run chmod on it,

Thats a very standard step for running scripts; regardless of language.

relying on a zig being in the PATH

Well yeah... no different to a python script assuming you have python in your PATH, or a perl script, etc.

[shawnl]

shebang is not even documented. While the Linux Standard Base got process initialization documented, shebang was left out. It is also kinda buggy, and has to be left that way to avoid breaking things: https://lwn.net/Articles/779997/

[shawnl]

I already touched this code in the stage2 locally, so assigning stage2 of this to myself.