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

Provide tests for keeping shebang lines in compiled CS files #3330

Closed
wants to merge 1 commit into from
Closed

Provide tests for keeping shebang lines in compiled CS files #3330

wants to merge 1 commit into from

Conversation

robertrossmann
Copy link

Shebang lines are currently ignored when CoffeeScript files are compiled to JavaScript. This makes it quite hard ( although not impossible ) to create executable scripts on Unix-based systems.

The resulting JavaScript file should preserve the shebang line from original CoffeeScript file if present and if it is on the first line of the document.

Since I am not that skilled to implement this functionality in the compiler myself I am at least sending the tests describing the expected functionality.

PS. This has been already discussed in #2216 although a conclusion has not been reached there.
Thank you!

The resulting JavaScript file should preserve the shebang line from
original CoffeeScript file, if present and if it is on the first line
of the document.
@epidemian
Copy link
Contributor

Hmm... I'd personally don't see the point of adding this to the compiler.

What should happen if a .coffee file has a #!/usr/bin/env coffee shebang (which makes sense if you want to execute it directly with coffee)? Should the sheband be preserved in that case?

And, does it make sense for a .coffee file to have a #!/usr/bin/env node shebang if, in fact, it can't be executed with node?

In general: why should the shebang be preserved in a process that translates between two different languages? The tools that can "run" these languages are most likely not going to be the same.

Besides, it's pretty easy to automate adding a shebang in a build process:

coffee -c my-script.coffee
echo '#!/usr/bin/env node' | cat - my-script.js > my-script.js.tmp && mv my-script.js.tmp test.js

@robertrossmann
Copy link
Author

I would expect the shebang line to stay in there no matter what. Here's why.

The shebang line is not really a CoffeeScript comment, even though it starts with a hash (#). It is a Shell directive that describes what executable should be used to process the contents of that file. Thus, if CS detects that directive on the first line of the file, it should keep it intact.

Having #!/usr/bin/env coffee in a CoffeeScript file only makes sense if you plan on executing the script without compiling it to JavaScript beforehand, which is fine. But for situations when you want to write your code in CS, compile it before publishing/use and then run it as native JavaScript application, it is a good idea to include a shebang line pointing to node.

Node itself ignores shebang lines in .js files even though # is an illegal character; consider:

#!/usr/bin/env node
// File: myexecutable.js
console.log('I am normal javascript!');

$ myexecutable.js # No error thrown

My opinion is that the programmer should know how a particular script is going to be executed - whether as CoffeeScript or JavaScript.

@davidchambers
Copy link
Contributor

Having #!/usr/bin/env node at the beginning of a CoffeeScript file seems confusing.

@robertrossmann robertrossmann deleted the preserve-shebang-lines branch January 28, 2014 19:13
@monokrome
Copy link

I feel like you should have #!/usr/bin/env coffee and if coffeescript detects a shebang as the first line (line starting with #!) then coffee-script should convert it into #!/usr/bin/env node. This could be done by simply checking that the last 4 characters of the line are coffee and replacing them with node instead so that other shebangs (EG, #!/usr/local/bin/coffee) aren't broken.

I think that if people are worried about this being too node-specific then that could be an option as well. Something like coffee -i jsc -o lib -c bin might solve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants