My site runs fine locally in development. However, deployed on digital ocean in the Ubuntu 16.04 environment, it breaks because the so-called ‘shebang’ line above, which is not in any of my original js code, nor directly in any of the js libraries I have incorporated into my project, errors in my browser console. The ‘’#!/usr/bin/env node’ line is line #29589 in a precompiled asset.
My assets were precompiled locally an are included in my repo. I removed them all from my Production host and ran rake assets:precompile there, but still get the error. I manually removed the line from the precompiled file in question, restarted unicorn and nginx, yet still get the error, which I completely don’t understand.
This isn’t my code, but it’s somehow breaking my production site for unknown reasons, and I doubt it should be.
Can anyone explain to me:
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.
@jcspampinato
The shebang is required if the NodeJS script is required to be executed from the CLI, without using
node
. It functions much in the same way the shebang does for a bash script.For example, let’s create two very basic NodeJS scripts:
demo01.js – w/o a shebang
demo02.js – w/ a shebang
If we run either
demo01.js
ordemo02.js
from the CLI using either:or
… we should see “Hello World” as the output. So why use a shebang in
demo02.js
? Well, if it needs to be ran from the CLI, like a bash script, it’s required – additionally, execution permissions would be set to allow it to be executed in that manor.For example, run
chmod +x demo01.js
and thenchmod +x demo02.js
. That’ll give the scripts their required permissions to execute as a script from the CLI, withoutnode
.Now run (without using
node
):and
demo01.js
fails with:… while
demo02.js
results in the same “Hello World” that was expected. The reason for this is because that shebang equates to runningnode demo02.js
.…
So the question becomes does one or more of the scripts that you’re compiling require the ability to execute as essentially a shell script (like
demo02.js
), and if so, is pre-compiling preventing that?Also, are you 100% sure that the environments are identical? Some use
node
, others usenodejs
. If you have either or and the shebang references the one you don’t have an executable for, it’ll fail.@jcspampinato
New reply due to response limits on the previous.
…
I would try to find the package that’s being compiled in which has the shebang, and then try to run without it to test whether it’s related to the problem, and thus, the error.
I mainly work with PHP/MySQL and Bash/Shell scripting, though similar issues exist when compiling NGINX and then using
include
to keep configuration files clean. You’ll often see an error that exists somewhere on the fully included source, but since you’re using includes, you have to manually open each file to find out where the issue may be (as the errors don’t correspond to included files).That seems to be a similar case here. When you build all the assets together, it throws and error and fails, much like how NGINX does with includes at times, thus you have to do a lot of manual work to find out where the source of the issue really is.
So I’d try to find what has the shebang and compile without the package first. If it succeeds, you’ve found the issue. If it doesn’t there may be other issues that exist.
@jcspampinato
In most all scenarios,
!#/usr/bin/env node
should work just fine as it should find the executable. I say should – but that’s definitely not the case here.It’s true that on older distros,
node
andnodejs
were two entirely different packages. As of Ubuntu 16.04/16.10, thenode
package that was causing the confusion seems to have been pulled.Differences in version can definitely cause some issues, I can confirm that from answering questions here in the community. What I might recommend doing would be to setup a test Droplet and use the repositories from NodeSource.
You can installer 4.x using:
You could then test the precompiled application against a 4.x release and see if it works. If it does, it may very well be a matter of versions (something was deprecated, removed, etc). If it doesn’t work, the issue may be between environments.
That’s what I’d do at least to test. I’d also take a look at the packages that are being installed during the compile. I’ve ran in to numerous abandoned packages and packages that hadn’t been updated for over a year with one question – they had no signs of coming back to update either.