/usr/bin/env: ‘node\r’: No such file or directory

Question

/usr/bin/env: ‘node\r’: No such file or directory

Ianfeather opened this issue 7 years ago · comments

Hey @dgautsch, did you just publish 2.6.0 from a windows machine?

bin/npm-register has been re-encoded with \r for line returns and this is causing the error above. There are similar issues across many projects so it seems to be fairly common, and fixed by specifying encoding:

abrjagad/npm-module-stats#1
nwutils/nw-builder#105

I was able to verify the fix by opening the file and setting line endings to unix :set ff=unix.

I also verified that 2.5.5 worked fine.

Quite a strange bug given that file hasn't changed but perhaps you reopened it before publishing 2.6.0?

Ianfeather commented 7 years ago

Will do

Jeff Dickey · Answer 1 · Thu Jan 11 2018 03:25:10 GMT+0800 (China Standard Time)

I bet we should probably add a .gitattributes file but I'm not that familiar with how those need to be written

Ianfeather · Answer 2 · Thu Jan 11 2018 03:26:37 GMT+0800 (China Standard Time)

Is that respected by npm too? The encoding in the file checked in to git is still unix based from what I see.

I can take a quick look into gitattributes

Jeff Dickey · Answer 3 · Thu Jan 11 2018 03:31:28 GMT+0800 (China Standard Time)

good point, you're probably right. I don't understand why npm isn't just copying the file wholesale I suppose

Ianfeather · Answer 4 · Thu Jan 11 2018 03:33:23 GMT+0800 (China Standard Time)

Yeah I can only guess that the file was open in an editor before publishing and it published an unstaged change? Very peculiar though - i've never seen this before. It looks like we could normalize it with an editorconfig:

root = true

[*]
charset = utf-8
end_of_line = lf

Ianfeather · Answer 5 · Thu Jan 11 2018 03:35:15 GMT+0800 (China Standard Time)

I can make a PR to add this if you like. It might require resaving any/all files.

fwiw when I did change the line endings using :set ff=unix git recognised that the file had changed.

Jeff Dickey · Answer 6 · Thu Jan 11 2018 03:40:21 GMT+0800 (China Standard Time)

editorconfig is a good thing and I put it in a lot of projects, but most editors don't look at it by default

Jeff Dickey · Answer 7 · Thu Jan 11 2018 03:40:47 GMT+0800 (China Standard Time)

we should also add a gitattributes file, one of those tickets you posted said that fixed their issue

Ianfeather · Answer 8 · Thu Jan 11 2018 03:41:46 GMT+0800 (China Standard Time)

ok, I can do this. Give me a few mins and I'll make a PR

Dan Gautsch · Answer 9 · Thu Jan 11 2018 06:47:23 GMT+0800 (China Standard Time)

Ah! Sorry everyone. I don't even open up the code in my editor in my machine. I cloned, then published. Sorry for this...

Dan Gautsch · Answer 10 · Thu Jan 11 2018 07:00:48 GMT+0800 (China Standard Time)

I'll check my git settings...I thought I told it to respect line endings and such.

Ianfeather · Answer 11 · Thu Jan 11 2018 15:43:35 GMT+0800 (China Standard Time)

No worries @dgautsch, I don't think it's your fault. Pretty unexpected.

Could you publish 2.6.1 when you get a chance?

Dan Gautsch · Answer 12 · Thu Jan 11 2018 22:57:42 GMT+0800 (China Standard Time)

@Ianfeather published, can you try again?

Ianfeather · Answer 13 · Fri Jan 12 2018 00:29:11 GMT+0800 (China Standard Time)

Sorry for the delay. GH went down and I got distracted.

Same issue with 2.6.1 :( I can resolve it in the same way manually too.

Are you able to reproduce this locally? I can reproduce this by npm installing to a fresh directory and running npm start.

Dan Gautsch · Answer 14 · Fri Jan 12 2018 03:13:13 GMT+0800 (China Standard Time)

@Ianfeather I know this won't run on windows because I had to fix it in my UI feature branch. So i'm not sure I can reproduce on my machine. This path ./bin/npm-register start won't work on a Windows box. I suggest we rewrite the start script to node bin/npm-register start That should work on all platforms.