Repository navigation
Remove shebang support #2165
Description
Activity
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
runas the parameter, and so still instead ofrunsubcommand, 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 executedzig run ....
- if the main script is zig code, use
- distributing software
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.
Reacted by Stevie Hryciw, Marc Tiehuis, Shawn Landden, Sahnvour, Komari Spaghetti, Joran Dirk Greef and Liam GermainI 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)Reacted by bb010g"just chmod +x it and run it"
If you're already having to run
chmodon it, and relying on a zig being in thePATH, 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.already having to run
chmodon 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.
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/
Reacted by Eira Fransham, Jan Ph. H. and Balázs OrbánI already touched this code in the stage2 locally, so assigning stage2 of this to myself.
- added a commit that references this issue
on Mar 19, 2025
Related:
runsubcommand, treat first positional argument as the zig run target #1505Currently 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:
Cons:
Counterarguments: