Sometimes the most critical fixes are the simplest. Today we shipped a one-file change that restored our deployment pipeline after shell scripts mysteriously stopped executing on Railway's Linux containers.
What Changed
We added a .gitattributes file to the repository root with a single directive:
deploy/*.sh text eol=lfThis forces Git to store and checkout all shell scripts in the deploy/ directory with Unix-style line endings (LF) regardless of the developer's operating system.
The problem: Windows developers checking in shell scripts were introducing CRLF line endings. When Railway's Linux containers tried to execute these scripts, the shell interpreter couldn't find the /bin/sh executable—because it was actually looking for /bin/sh\r (with a carriage return character). Result: 'cannot execute: required file not found' errors and failed deployments.
Why It Matters
This isn't just a historical curiosity from the days when Windows and Unix couldn't agree on newline conventions. Cross-platform development is the norm in 2026, and these issues still surface regularly—especially in CI/CD pipelines where shell scripts are execution-critical.
For Strug Works, this meant the difference between shipping and being blocked. Our deployment automation depends on shell scripts for environment setup, health checks, and rollback procedures. When those scripts fail silently with cryptic error messages, troubleshooting becomes expensive.
The fix is small, but the impact is significant: consistent, predictable deployments regardless of which team member committed the code or what OS they're running locally.
Honest Assessment
This should have been in place from day one. .gitattributes is standard practice for repositories containing shell scripts, and it's a reminder that infrastructure discipline matters as much as application code.
We caught this quickly because our deployment frequency is high—failed deploys surface fast. In a lower-cadence environment, this kind of issue can linger and cause confusion when someone eventually tries to ship.
The error message itself ('required file not found') was misleading. It pointed at a missing executable rather than a line ending issue. Better tooling or pre-commit hooks could catch this class of problem before it reaches production infrastructure.
What's Next
We're auditing other file types that might benefit from explicit line ending rules—particularly configuration files and scripts outside the deploy/ directory. This includes Python scripts, YAML configs, and any other execution-sensitive files.
We're also evaluating pre-commit hooks that validate line endings locally before code reaches CI. The goal: catch these issues in development, not during deployment.
Finally, we're documenting this as a standard practice for all Strug City repositories. Small fixes like this become institutional knowledge when they're written down and integrated into onboarding.
Line endings may seem trivial, but deployment reliability isn't. This fix is live, and our Railway pipelines are back to normal.