Skip to content

fix(build): pin shell scripts to LF endings to unblock Docker builds on Windows clones#9

Open
Kures wants to merge 1 commit into
nullclaw:mainfrom
Kures:fix/shell-line-endings
Open

fix(build): pin shell scripts to LF endings to unblock Docker builds on Windows clones#9
Kures wants to merge 1 commit into
nullclaw:mainfrom
Kures:fix/shell-line-endings

Conversation

@Kures
Copy link
Copy Markdown

@Kures Kures commented May 12, 2026

PR3 — fix(build): pin shell scripts to LF endings to unblock Docker builds on Windows clones

Branch: fix/shell-line-endings

The bug

Without a .gitattributes, git on Windows checks out shell scripts
with CRLF line endings (the default
core.autocrlf=true behavior). Inside the alpine builder image used
by Dockerfile, bash chokes on the trailing CR and aborts the build:

#20 0.196 /tmp/install-zig.sh: line 2: set: pipefail
: invalid option name
#20 ERROR: process "/bin/sh -c set -eu; ..." did not complete successfully: exit code: 2

pipefail itself is a perfectly valid bash option. The trailing \r
makes bash see the option name as pipefail\r, which it does not
recognize.

Reproducer

  1. Clone the repo on Windows with the default core.autocrlf=true.
  2. cd nullboiler && docker compose up --build.
  3. Stage [builder 4/9] fails before zig is even installed.

The same clone on Linux/macOS works because their default is
core.autocrlf=input (or off), so files stay LF.

The fix

Add .gitattributes pinning shell scripts and Dockerfiles to LF:

*.sh         text eol=lf
*.bash       text eol=lf
Dockerfile   text eol=lf
*.dockerfile text eol=lf

* text=auto

text eol=lf overrides any user-side core.autocrlf setting. After
this PR merges, fresh clones produce LF working trees on every
platform; existing clones with CRLF working trees can re-normalize via:

git rm --cached -r .
git checkout .
# or simpler: re-clone

Why this is a real issue worth fixing

  • Anyone running docker compose up --build from a Windows clone
    hits this. We hit it during this contribution work.
  • The fix is a 13-line .gitattributes with zero behavioral change on
    Linux/macOS (those checkouts already had LF).
  • Without this fix, the project's own quick-start in the README does
    not work on Windows.

Why review attention is low-risk

  • One file added. No code, no docs, no scripts touched.
  • Shell scripts on disk are unchanged on Linux/macOS contributors'
    machines.
  • The * text=auto final rule preserves git's default
    text-vs-binary detection for every other file type.

…on Windows clones

Without .gitattributes, git checking out the repository on Windows
auto-converts shell scripts to CRLF. Inside the alpine builder image,
bash chokes on the trailing CR and aborts the build with errors like:

    /tmp/install-zig.sh: line 2: set: pipefail
    : invalid option name

This is a clean reproducer:
  1. Clone on Windows with default git autocrlf
  2. docker compose up --build
  3. Stage [builder 4/9] fails before zig is even installed.

Fix: add .gitattributes pinning *.sh, *.bash, Dockerfile to eol=lf.
Future clones are immune regardless of core.autocrlf setting.

No code changes. The same scripts work as before on Linux/macOS where
LF was already the local form.

Note for existing Windows clones: tracked files won't auto-renormalize
on pull. After pulling this fix, run

    git rm --cached -r .
    git checkout .

(or simpler: re-clone) to convert your working tree to LF.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant