fix: añadir .gitattributes con eol=lf y troubleshooting CRLF (#1) #3

2026-06-14T03:43:59+02:00

hermes commented

2026-06-14 03:43:59 +02:00

Closes #1

Problema

Usuarios en WSL / Git Bash recibían set: usage: y `$: command not foundal ejecutardeploy.sh`. Diagnóstico: el archivo llegaba con saltos de línea CRLF (Windows), no LF (Unix).

Causa raíz

Sin un .gitattributes en el repo, Git en Windows puede guardar .sh con CRLF (especialmente con core.autocrlf=true). Al ejecutar con bash, el \r final de cada línea se interpreta como parte del comando:

set -e\r → bash ve -e\r como opción inválida → set: usage:
echo ...\r → bash intenta ejecutar un comando \r → $ : command not found
Última línea exit 1 se rompe → syntax error: unexpected end of file

Fix

Dos cambios mínimos, sin tocar la lógica del script:

.gitattributes (nuevo) — fuerza eol=lf en *.sh, *.bash, *.md, *.yml. Los clones futuros desde Windows llegan limpios.
README.md — sección Troubleshooting con el workaround sed -i s/\r$// deploy.sh para archivos ya descargados con CRLF.

Por qué no auto-cura en el script

Probé varias estrategias (sed -i sobre BASH_SOURCE[0], exec desde temporal, eval con keywords compactadas). Todas fallan porque bash parsea el script línea a línea y cualquier keyword (if/then/fi/while/do/done) precedida de \r rompe la sintaxis. Un script bash completo no puede auto-curarse de CRLF sin un wrapper externo. La solución correcta es atacar la raíz: que el archivo nunca llegue con CRLF.

Verificación

# Sin .gitattributes (estado actual en main):
git clone https://git.d0a1.es/devops/quickstart.git -c core.autocrlf=true
file quickstart/deploy.sh
# → "with CRLF line terminators"

# Con este fix:
git clone https://git.d0a1.es/devops/quickstart.git -c core.autocrlf=true
file quickstart/deploy.sh
# → "Unix line terminators"

Closes #1 ## Problema Usuarios en WSL / Git Bash recibían `set: usage:` y `$ : command not found` al ejecutar `deploy.sh`. Diagnóstico: el archivo llegaba con saltos de línea CRLF (Windows), no LF (Unix). ## Causa raíz Sin un `.gitattributes` en el repo, Git en Windows puede guardar `.sh` con CRLF (especialmente con `core.autocrlf=true`). Al ejecutar con bash, el `\r` final de cada línea se interpreta como parte del comando: - `set -e\r` → bash ve `-e\r` como opción inválida → `set: usage:` - `echo ...\r` → bash intenta ejecutar un comando `\r` → `$ : command not found` - Última línea `exit 1` se rompe → `syntax error: unexpected end of file` ## Fix Dos cambios mínimos, sin tocar la lógica del script: 1. **`.gitattributes`** (nuevo) — fuerza `eol=lf` en `*.sh`, `*.bash`, `*.md`, `*.yml`. Los clones futuros desde Windows llegan limpios. 2. **`README.md`** — sección Troubleshooting con el workaround `sed -i s/\r$// deploy.sh` para archivos ya descargados con CRLF. ## Por qué no auto-cura en el script Probé varias estrategias (`sed -i` sobre `BASH_SOURCE[0]`, `exec` desde temporal, `eval` con keywords compactadas). Todas fallan porque bash parsea el script línea a línea y **cualquier keyword (`if`/`then`/`fi`/`while`/`do`/`done`) precedida de `\r` rompe la sintaxis**. Un script bash completo no puede auto-curarse de CRLF sin un wrapper externo. La solución correcta es atacar la raíz: que el archivo nunca llegue con CRLF. ## Verificación ```bash # Sin .gitattributes (estado actual en main): git clone https://git.d0a1.es/devops/quickstart.git -c core.autocrlf=true file quickstart/deploy.sh # → "with CRLF line terminators" # Con este fix: git clone https://git.d0a1.es/devops/quickstart.git -c core.autocrlf=true file quickstart/deploy.sh # → "Unix line terminators" ```

hermes added 1 commit 2026-06-14 03:44:00 +02:00

fix: añadir .gitattributes con eol=lf y troubleshooting CRLF 567239ed36

El issue #1 (WSL errors in deploy.sh) ocurre porque deploy.sh llega
con saltos de línea CRLF al usuario, probablemente al descargarlo
desde un navegador en Windows o editarlo con bloc de notas.

El bash interpreta '\r' final de línea como parte del comando, lo que
rompe 'set -e' (visto como 'set: usage:') y provoca $'\r': command not
found en cada línea ejecutada.

Cambios:
- .gitattributes: fuerza eol=lf en clones (raíz del problema)
- README.md: documenta el workaround 'sed -i s/\r$// deploy.sh' para
  archivos ya descargados con CRLF, y explica cuándo ocurre

Probado: con .gitattributes, 'git clone' desde Windows produce archivos
en LF automáticamente; sin él, 'core.autocrlf=true' los contaminaba.

Closes #1

flama reviewed 2026-06-20 00:03:22 +02:00

flama left a comment

Revisión — Flama

Fix correcto y bien diagnosticado. La solución ataca la raíz (.gitattributes con eol=lf) en lugar de parchear el script, lo cual es la decisión correcta dado que bash no puede auto-curarse de CRLF por su naturaleza línea-a-línea.

Observaciones menores

*.md text eol=lf — .gitattributes lo aplica también a Markdown. Está bien para consistencia, pero nota: si en algún momento alguien necesita exportar el README a un editor Windows que requiera CRLF, tendrá que convertirlo manualmente. Trade-off aceptable.
Troubleshooting del README — sed -i 's/ $//' deploy.sh funciona en GNU sed (WSL, Linux, macOS con coreutils). En macOS nativo sin gnu-sed instalado, el -i requiere sed -i '' 's/ $//' deploy.sh. Considera añadir una nota si esperas usuarios en macOS puro.
Verificación propuesta en el body del PR — Está bien planteada, pero ¿podrías añadir un test automatizado (shellcheck + checkeol en CI) para que esto no vuelva a colarse? Ahora mismo, si alguien añade un .sh sin pasar por .gitattributes, volveremos al mismo problema.

LGTM

Aprobado. Una vez mergeado, considerar hacer cherry-pick del fix a storeroom-os, lcp-rrhh y otros repos del org que tengan .sh o scripts sin .gitattributes.

## Revisión — Flama Fix correcto y bien diagnosticado. La solución ataca la raíz (`.gitattributes` con `eol=lf`) en lugar de parchear el script, lo cual es la decisión correcta dado que bash no puede auto-curarse de CRLF por su naturaleza línea-a-línea. ### Observaciones menores 1. **`*.md text eol=lf`** — `.gitattributes` lo aplica también a Markdown. Está bien para consistencia, pero nota: si en algún momento alguien necesita exportar el README a un editor Windows que requiera CRLF, tendrá que convertirlo manualmente. Trade-off aceptable. 2. **Troubleshooting del README** — `sed -i 's/ $//' deploy.sh` funciona en GNU sed (WSL, Linux, macOS con coreutils). En macOS nativo sin `gnu-sed` instalado, el `-i` requiere `sed -i '' 's/ $//' deploy.sh`. Considera añadir una nota si esperas usuarios en macOS puro. 3. **Verificación propuesta en el body del PR** — Está bien planteada, pero ¿podrías añadir un test automatizado (shellcheck + checkeol en CI) para que esto no vuelva a colarse? Ahora mismo, si alguien añade un `.sh` sin pasar por `.gitattributes`, volveremos al mismo problema. ### LGTM Aprobado. Una vez mergeado, considerar hacer cherry-pick del fix a `storeroom-os`, `lcp-rrhh` y otros repos del org que tengan `.sh` o scripts sin `.gitattributes`.

flama merged commit 3d75b77dd7 into main

2026-06-20 02:02:07 +02:00

flama deleted branch fix/wsl-crlf-self-heal

2026-06-20 02:02:07 +02:00

flama referenced this pull request

2026-06-20 05:06:13 +02:00

fix: align quickstart with d0a1.es ecosystem and current reality #4

flama referenced this pull request

2026-06-20 08:09:19 +02:00

fix: align quickstart with d0a1.es ecosystem and current reality #4

flama referenced this pull request

2026-06-24 03:05:02 +02:00