English

Pasa tus scripts de shell por ShellCheck primero

Tu asistente de IA escribe bash con los mismos bugs de comillas que tú. Aprendió shell de los mismos scripts que enseñaron a los humanos a escribir rm -rf $DIR/ — y, igual que un humano, te va a entregar código que funciona en el camino feliz y explota con un nombre de archivo con espacios. La solución no es un mejor prompt. Es un pipeline: lint, luego formato, luego pruebas — en ese orden.

Por qué lint antes que pruebas

La mayoría de los bugs de shell no son de lógica. Son defectos estáticos: una expansión de variable sin comillas, una comparación [ ] que falla con cadenas vacías, un bashism dentro de un script #!/bin/sh. Una prueba de comportamiento puede pasar 100 veces mientras una variable sin comillas espera la primera ruta con un espacio.

Esa es la trampa específica de los scripts generados por IA: el modelo produce algo plausible, lo ejecutas una vez, funciona, lo publicas. Un linter lee el script como el shell lo va a parsear, no como resultó ejecutarse — y detecta toda la clase de defectos de una vez, en lugar de un crash a la vez.

ShellCheck es la herramienta estándar: análisis estático para scripts sh/bash, recomendada por la Google Shell Style Guide "para todos los scripts, grandes o pequeños". Cada hallazgo tiene una página wiki con el patrón exacto y su corrección, lo que también la vuelve material perfecto para pegarle de vuelta a tu asistente de IA.

El pipeline de tres etapas

Dos hallazgos de ShellCheck justifican todo el esfuerzo por sí solos:

• SC2086 — "Double quote to prevent globbing and word splitting." echo $1 se divide por espacios y expande globs; echo "$1" no. Es el bug de shell generado por IA más común.
• SC2154 — "var is referenced but not assigned." Una variable mal escrita en bash no es un error: es una cadena vacía. Silenciosa, y letal en una ruta de rm.

Después, shfmt normaliza el formato (-l lista los archivos que cambiarían, -w reescribe en el lugar), y Bats — un framework de pruebas compatible con TAP para Bash 3.2+ — cubre el comportamiento con archivos .bats, el helper run para invocar comandos y hooks setup/teardown.

Prueba los caminos que la IA nunca imagina

• Rutas con espacios. Ejecuta el script desde "/tmp/my dir/" y pásale nombres de archivo con espacios. Ahí aflora cada SC2086 que el linter no atrapó.
• Variables de entorno faltantes. Elimina las variables que el script asume que existen y confirma que falla de forma ruidosa en lugar de operar sobre cadenas vacías.
• Salida vacía. No le pases nada por el pipe. Los loops sobre $(cmd) se comportan muy distinto con cero resultados.

Trucos avanzados

• Bloquea el CI con esto. ShellCheck usa códigos de salida de forma canónica, así que shellcheck scripts/*.sh en CI rompe el build cuando hay hallazgos. --severity=warning limita la salida a errores y advertencias cuando lo adoptas en un repo legado.
• Salida legible por máquinas para agentes. ShellCheck emite formatos JSON y compatibles con GCC — dale el JSON directo a tu asistente de IA y pídele corregir cada hallazgo por código. La página wiki de cada código (p. ej. shellcheck.net/wiki/SC2086) es contexto ideal.
• Lint en el editor. ShellCheck se integra con VS Code, Vim, Emacs y Sublime, así el shell sugerido por la IA se marca en cuanto aparece en el buffer — antes de guardar.
• Sin instalar nada para empezar. Pega un script en shellcheck.net y obtén resultados al instante.

Recursos

• ShellCheck — repositorio y documentación en GitHub
• SC2086: Double quote to prevent globbing and word splitting
• SC2154: var is referenced but not assigned
• shfmt — formateador de shell (mvdan/sh)
• Documentación de Bats-core
• Google Shell Style Guide