Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove shebang support #2165

Open
hryx opened this Issue Apr 2, 2019 · 6 comments

Comments

Projects
None yet
5 participants
@hryx
Copy link
Contributor

hryx commented Apr 2, 2019

Related:


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 andrewrk added the proposal label Apr 2, 2019

@andrewrk andrewrk added this to the 0.5.0 milestone Apr 2, 2019

@andrewrk andrewrk added the breaking label Apr 2, 2019

@andrewrk

This comment has been minimized.

Copy link
Member

andrewrk commented Apr 2, 2019

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 #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

This comment has been minimized.

Copy link
Contributor

daurnimator commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Contributor

tgschultz commented Apr 2, 2019

"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

This comment has been minimized.

Copy link
Contributor

daurnimator commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Contributor

shawnl commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Contributor

shawnl commented Apr 6, 2019

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

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

shawnl added a commit to shawnl/zig that referenced this issue Apr 10, 2019

@shawnl shawnl referenced a pull request that will close this issue Apr 10, 2019

Open

remove Shebang (#!) support #2241

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.