fix: docker container fails to start due to CRLF line endings in start.sh

[rockyxwall]

Problem Description

The YOLO ML backend Docker container was failing to start with the error:

exec /app/start.sh: no such file or directory
yolo exited with code 255

This error occurs when the start.sh shell script contains Windows-style line endings (CRLF - \r\n) instead of Unix-style line endings (LF - \n). When Docker tries to execute the script, the shell interpreter cannot find the correct interpreter path because it's looking for /bin/bash\r instead of /bin/bash.

Root Cause

• The start.sh file was created or edited on Windows, which uses CRLF (\r\n) line endings
• Git may have converted LF to CRLF during checkout depending on core.autocrlf settings
• Linux/Docker expects Unix-style LF (\n) line endings for shell scripts
• The invisible \r character causes the shebang line to fail

Impact

• Container fails to start entirely
• Affects users on Windows or anyone who has edited the file with Windows line endings
• Makes the Docker setup non-functional out of the box for Windows developers

Solution

Added line ending normalization and permission setting in the Dockerfile to ensure the script works regardless of the development environment.

Changes Made

Modified: Dockerfile

ENV PYTHONPATH=/app
# Normalize line endings and ensure script is executable
RUN sed -i 's/\r$//' /app/start.sh && chmod +x /app/start.sh
CMD ["/app/start.sh"]

Why This Fix Works

1. sed -i 's/\r$//' removes carriage return characters from line endings
2. chmod +x ensures the script has execute permissions
3. .gitattributes prevents Git from converting line endings in the future
4. The fix happens during Docker build, so it works regardless of the host OS

Testing

Tested on:

• Windows with docker-compose up --build
• Verified container starts successfully
• Confirmed ML backend responds on port 9090

Additional Notes

This is a common issue when developing cross-platform Docker containers. The fix ensures compatibility across Windows, macOS, and Linux development environments without requiring users to manually fix line endings.

Alternative Solutions Considered

1. ❌ Requiring users to run dos2unix locally - adds dependency and manual step
2. ❌ Using ENTRYPOINT with shell form - doesn't solve the root cause
3. ✅ Normalizing during build - works automatically for all users

Checklist

• Tested the fix locally
• Container starts successfully
• No breaking changes to existing functionality