I’m not sure what that error is. Looks like perhaps a text encoding issue within the container (which is weird and kinda opposite the expectation of container-based deployment). The resolution of the images is pretty poor, so it’s hard to tell for certain.
I don’t currently have a Docker for Windows environment running anywhere but I may be able to spin one up in a few hours to see if it’s a platform issue when running on windows.
Can you explain what the ¥ character is on your system/terminal?
It crops up in that “missing file name” in the last screenshot, and like pillbox I initially though that an encoding problem might be behind that seemingly bad filename – but then I looked at the earlier screenshots and that same character seems to be all over the place for your local system.
That’s how \ displays in my cmd line. Not sure why.
We used to have that happen all the time at work. I think it is due to some combination of fonts and language settings (Japanese overrides the Unicode backslash with the Yen symbol).
I believe they should still be interpreted correctly because they are the same Unicode character, although I am far from an expert on using the command line.
Huh. I did have both English and Japanese set as languages. No idea why. Removed Japanese and restarted. Still getting the same error and the ¥ are still there and replacing \ in the cmd line.
Could be that Japanese changed the default command line font? If you right click the Command Prompt window title, you should be able to select properties and go to the font tab. I think it is MS Gothic that turns backslashes into Yen symbols? If you switch to Consolas or Lucida Console they should go away. If that wasn’t the problem then I’m afraid that’s the extent of my knowledge.
I doubt that will help with the error, but you never know.
Yeah the font was the cause of the ¥. Error is still there after that though.
I feel like I’ve just stumbled into a software stand-up at work…
When I opened this can of worms I knew you would all be amazing.
Ah, so it’s actually saying that it’s failing to find:
node_modules/coffeescript/bin/coffee\r
I strongly suspect that \r will represent a carriage return.
So it should be looking for coffee, but a carriage return has gotten into the string for the path it’s using. As everything other than the null character is (strictly) allowed in filenames, a file by that name isn’t invalid – but of course doesn’t actually exist.
I can’t be confident about how that’s happening, but as you’re running on Windows which has always liked CRLF rather than just LF for line endings, I’m assuming it’s related. Perhaps that’s a locale feature, and hosting on Windows affects that? I’m merely speculating at this point.
Have a look at how that file path gets generated, for starters.
This is exactly the issue, and a near-complete explanation for what’s happening.
I think I have a workaround. Standby
I’ve fiddled with the .gitattributes file in the repo that should heavy-handedly force LF line-endings. Bad for anyone doing native Windows deployment, but good for anyone using Windows git.exe to pull the files for use with (linux) docker containers.
Not exactly sure if you can just git pull to get the complete changes because line-endings in git are actually a bit magical.
I also update the README.md with new instructions. Completely ignore the original instructions.
Fetched your commits. Got this error on the docker exec -it shintolin-1_shintolin3_1 bash step- Daemon Error - Album on Imgur
There was this in docker- CONTAINERSAttaching to shintolin-1_shintol - Pastebin.com
If the problem is just Windows and everything works in Linux I’m willing to change my OS. Had been thinking about it anyways because I don’t want to move to Windows 11.
No worry. You don’t need to be in the same exact container, actually.
docker-compose run shintolin3 bash will get you a prompt that you can run that command from
After you do that and run the bootstrap-production script, exit from the container shell and then restart the whole stack:
docker-compose down
docker-compose up -d
Still getting
C:\Users\austi\Documents\GitHub\shintolin-1>docker-compose run shintolin3 bash
Creating shintolin-1_shintolin3_run … done
root@37f3a2bcf1bc:/usr/src/app# bin/dev/bootstrap-production shintolin.tsv
/usr/bin/env: ‘node_modules/coffeescript/bin/coffee\r’: No such file or directory
I saw you forked my fork. Are you pulling from mine or yours? If the latter, did you update your fork?
It’s working! Thank you so much! For the record since the solution was suggested in a pm. Deleting my local files and pulling into a different directory solved my problems.
My plans are to start off making the easy QoL changes a lot of us on the discord have been talking about. Changing numeral values to make the daze mechanic less terribly unfun. An improved map. Adding walls back. There are some more complicated things I’d like to add/change that will take a bit more work. I’ll be making a thread in the discord about possible edits soon to get feedback. Once I have a build that makes enough of a change to be worthwhile I’ll start looking into hosting it.
I love that people here both know how to and are willing to help out a stranger with esoteric docker/git problems 
Hope you enjoy the result @Juraz!
