[BUG] running "docker-compose up" returns lots of errors about bash being a bad interpreter because of ^M

[iandouglas]

Describe the bug When starting out fresh with tau as of today's build, running "docker-compose-up" fails with a ^M character attached to a reference to /bin/bash

To Reproduce Steps to reproduce the behavior:

1. clone the repo on Windows
2. set up .env
3. run "docker-compose up"
4. see lots of this:

   bash: ./scripts/start.sh: /bin/bash^M: bad interpreter: No such file or directory

Expected behavior Expect to NOT see this error and see something indicating that it all started successfully?

Screenshots

Deployment:

• Docker Version: Docker version 20.10.17, build 100c701
• Docker Compose Version (if applicable): docker-compose version 1.29.2, build 5becea4c
• Deployment Type: Local
• Deployment Details: n/a

Additional context First time user

[iandouglas]

Running "dos2unix" on the script, and removing all containers and storage from Docker Desktop then throws an error about this instead:

[iandouglas]

You can use cat -vte to see line endings, etc:

 $ cat -vte manage.py | head
#!/usr/bin/env python^M$
"""Django's command-line utility for administrative tasks."""^M$
import os^M$
import sys^M$

[iandouglas]

Ran dos2unix on the manage.py and wait_for_postgres.py and things seem to be working better now.

[iandouglas]

FWIW, it's possible that this is a Windows "git" command issue that converts LF to CRLF, and not sure if that's correctable by the deployment process or if I just need to do better with my Git setup ...

[FiniteSingularity]

Hi @iandouglas. Thank you for the issue. Yes, there is an issue with how windows git treats line endings, and it causes exactly the same behavior that you're seeing. I could have sworn that we had this in the documentation, but upon looking, I am not finding it. I'll need to update the docs to indicate this.

The way to fix it, is set git's autocrlf to false for windows installs, e.g.:

git config core.autocrlf false

This will keep git windows from converting the line-endings to windows line-endings. Another (preferred) option, is to do everything in WSL, as even docker performs significantly better when run from WSL these days.