A lo largo del módulo has escrito "$RUTA_CSV", "$@", ${fecha} y ${VELOZ_UMBRAL:-50} siguiendo instrucciones, sin una explicación completa de por qué. Esta lección paga esa deuda, y no es un detalle menor: la inmensa mayoría de los bugs de scripting en Bash —los que aparecen tres meses después, con un fichero que tenía un espacio en el nombre o una variable que llegó vacía— son problemas de comillas y expansión. Entender el orden exacto en que Bash procesa una línea es lo que separa un script que funciona casi siempre de uno que funciona siempre.

1. El orden de las expansiones
2. Comillas dobles, simples y sin comillas
3. Entrecomillar siempre las variables, y el escape con \
4. Expansión de parámetros: valores por defecto y validación
5. Sustitución de comandos y expansión aritmética
6. IFS y la división en palabras
7. El desastre de for f in $(ls)
8. printf frente a echo
9. Repaso final de informe-diario.sh

Antes de ejecutar cualquier comando, Bash transforma la línea que has escrito siguiendo siempre la misma secuencia, y conocerla explica casi todo lo demás:

Con ejemplos concretos: las llaves convierten envios-{01,02}.csv en dos nombres; la tilde convierte ~/veloz-ops en /home/joan/veloz-ops; los parámetros convierten $RUTA_CSV en la ruta del CSV; la sustitución de comandos convierte $(date +%F) en 2026-08-03; la aritmética convierte $(( 3 * 4 )) en 12; la división en palabras parte el resultado en argumentos; y el globbing convierte *.csv en los ficheros que existen.

La clave de toda la lección está en el orden de los pasos 3 y 6. Bash primero sustituye la variable por su valor, y después parte el resultado en palabras por los espacios. Es decir: si una variable contiene espacios, esos espacios se convierten en separadores de argumentos después de que la variable haya desaparecido.

Las comillas dobles no impiden que la variable se expanda; impiden el paso 6, la división en palabras. Ese es todo su secreto.

Bash ofrece tres niveles de protección, y esta tabla resume qué ocurre en cada uno:

Las filas en negrita son las que importan: las comillas dobles expanden variables pero bloquean la división en palabras y el globbing, que es justo lo que quieres el 95% de las veces.

Con echo la diferencia entre las dos primeras parece cosmética, pero con mkdir o rm es catastrófica: mkdir $ciudad crearía dos directorios, San y Sebastián. Las comillas simples, por su parte, son absolutas: nada se expande dentro, ni siquiera la barra invertida. Son la elección correcta para expresiones regulares (05-04), patrones de sed (06-02) y cualquier texto que deba llegar literal a otro programa:

Si esos patrones fueran con comillas dobles, Bash intentaría expandir $3 como una variable —que estaría vacía— y awk recibiría { print }: un fallo silencioso perfecto. Como las comillas simples no admiten escapes, para incluir una comilla simple dentro hay que cerrarlas, escapar y reabrir: 'no'\''funciona' produce no'funciona. Es feo, pero es la única forma.

La norma profesional es simple y no tiene apenas excepciones: entrecomilla toda expansión de variable, siempre. Estos son los tres desastres que evita. Rutas con espacios: wc -l $fichero se parte en varios argumentos. Con un comando destructivo, rm -rf $directorio sobre directorio="/srv/veloz datos" borraría /srv/veloz y datos.

Variables vacías: al expandirse sin comillas, una variable vacía desaparece por completo en lugar de convertirse en una cadena vacía:

Sin comillas, test recibe [ = Bilbao ] y no entiende nada, porque el primer operando se ha esfumado antes de que lo viera. Recuerda de 03-03 que [[ ]] es inmune a esto; [ ] no.

Globbing accidental: es el caso de las dos últimas líneas, si una variable contiene * o ?, sin comillas Bash intenta expandirla contra los ficheros del directorio. Es especialmente traicionero porque el script funciona hasta que alguien crea un fichero con el nombre equivocado en el directorio de trabajo.

Las únicas excepciones razonables son el interior de [[ ]] a la izquierda del operador, el interior de (( )), y los casos en que quieres deliberadamente la división en palabras. Ante la duda, entrecomilla: poner comillas de más nunca ha roto un script; ponerlas de menos, todos los días.

La barra invertida \ protege un único carácter del siguiente paso de procesamiento:

Por ejemplo, echo "El coste es \$50" imprime El coste es $50, y en echo Fichero:\ envios\ julio.csv los espacios escapados no separan palabras. Dentro de comillas dobles, la barra invertida solo tiene efecto sobre cuatro caracteres: $, `, " y \ (y el salto de línea). Ante cualquier otro se imprime literalmente, de modo que echo "ruta\nueva" produce ruta\nueva. Ese detalle sorprende a quien viene de otros lenguajes: echo "\n" no imprime un salto de línea en Bash por defecto. Para eso hace falta echo -e o, mejor, printf (apartado 8).

Al final de una línea, la barra invertida escapa el propio salto de línea y permite partir comandos largos, que es lo que has visto en todos los scripts del módulo. Cuidado: no puede haber ni un espacio después de la \. Si lo hay, la barra escapa ese espacio en lugar del salto y el comando se rompe con un error desconcertante.

La familia ${var...} va mucho más allá de leer un valor; estas cinco formas son las de uso diario:

${var:?} es la joya de la familia para scripts de producción: convierte una variable obligatoria sin valor en una muerte inmediata con mensaje claro, en lugar de dejar que el script siga adelante con rutas vacías. Compara los dos escenarios: sin él, rm -rf "$DIR_TEMPORAL/"* con la variable vacía se convierte en rm -rf /*. Con ${DIR_TEMPORAL:?}, el script muere antes de llegar ahí.

${var:+val} parece rebuscada, pero resuelve muy bien la construcción de opciones condicionales: filtro="${ciudad:+--ciudad $ciudad}" produce --ciudad Bilbao si hay ciudad y una cadena vacía si no. Un matiz sobre los dos puntos: ${var-def} (sin :) solo aplica el valor por defecto si la variable no existe, mientras que ${var:-def} lo aplica también si existe pero está vacía; en la práctica casi siempre quieres la versión con :.

Las operaciones de manipulación de cadenas de la misma familia —${var#patron}, ${var/a/b}, ${var^^}, ${var:0:5}— son la lección 04-04.

Ya usas $(comando) desde 03-02; aquí van los tres matices que faltaban. Entrecomíllala siempre, por el mismo motivo que las variables: su resultado sufre división en palabras. Y se anida sin escapes, que es su gran ventaja sobre las comillas invertidas:

Fíjate en que las comillas dobles internas de la última línea funcionan perfectamente: dentro de $( ) empieza un contexto nuevo, así que puedes volver a usar comillas dobles sin escaparlas. Con `...` habría que escapar cada nivel, y con dos niveles ya resulta ilegible.

La expansión aritmética $(( )) no necesita comillas internas pero sí externas si el resultado se usa como argumento. Dentro de $(( )) no hay división en palabras ni globbing —solo aritmética—, así que ahí las variables van sin $ y sin comillas sin ningún riesgo: es la única zona de Bash donde puedes relajarte.

IFS (Internal Field Separator) es la variable que le dice a Bash por qué caracteres partir en palabras en el paso 6. Su valor por defecto son tres: espacio, tabulador y salto de línea (compruébalo con printf '%q\n' "$IFS"). Cambiarlo permite dividir por otro carácter, lo cual es muy útil con datos separados por comas:

Ese IFS=',' read es el patrón canónico para trocear una línea de CSV, y tiene un detalle importante: al poner la asignación delante del comando, IFS solo cambia durante esa invocación (lección 03-02) y se restaura sola después. Ese es el uso seguro. Modificar IFS de forma global —una línea IFS=',' suelta en mitad del script— es peligroso, porque afecta a todo lo que venga después y hay que restaurarlo a mano con IFS=$' \t\n'. Si olvidas restaurarlo, comandos posteriores que dependan de la división por espacios se comportarán de forma inexplicable. La práctica correcta es guardar el valor original (IFS_ORIGINAL=$IFS) y devolverlo, o mejor aún, usar la forma de una sola invocación.

Este antipatrón merece su propio apartado porque es el error más repetido en scripts de principiante, y reúne casi todos los conceptos de la lección. Nunca escribas for f in $(ls /srv/veloz/datos). Qué falla, punto por punto:

• Los nombres con espacios se parten. envios julio.csv produce dos vueltas del bucle, con envios y julio.csv. Y los nombres con salto de línea (raros pero legales) rompen cualquier suposición.
• El globbing se aplica al resultado. Si un fichero se llama *, $(ls) lo devuelve y Bash lo expande contra el directorio.
• ls da formatos distintos según si su salida va a un terminal o a una tubería, y según opciones y alias del usuario. Además es un proceso de más, innecesario por completo.

La solución correcta es usar globbing directamente, que Bash gestiona sin dividir en palabras:

Cada $f es un nombre completo aunque contenga espacios, porque el globbing produce una lista de palabras ya separadas, no una cadena que haya que trocear. Recuerda de 02-05 que si el patrón no casa con nada, sin nullglob el bucle da una vuelta con el patrón literal; de ahí la guarda [[ -f "$f" ]].

La misma lógica desaconseja for linea in $(cat fichero): para recorrer líneas se usa while IFS= read -r linea; do ... done < fichero, que es la lección 04-01. Ese IFS= vacío al principio, por cierto, evita que read recorte los espacios del inicio y el final de cada línea; junto con -r, forma el idioma más seguro para leer texto en Bash.

echo es cómodo pero no es predecible: su comportamiento con opciones y barras invertidas varía entre shells, entre versiones e incluso según la opción xpg_echo. ¿echo "-n" imprime -n o lo interpreta como opción? ¿echo "a\tb" produce un tabulador o el texto literal? Depende del shell. printf es POSIX, uniforme en todas partes, y además da control sobre el formato:

Dos características muy útiles. printf reutiliza el formato hasta agotar los argumentos, así que printf '%s\n' "$@" imprime cada argumento en su propia línea. Y %q escapa la salida para que sea reutilizable por el shell, lo que la convierte en la mejor herramienta para depurar valores con espacios: printf 'valor: %q\n' "$ciudad" imprime valor: San\ Sebastián.

Regla práctica: echo para mensajes simples e interactivos, printf en scripts serios, y siempre printf cuando el formato importe o el contenido pueda empezar por guion.

Cerramos el módulo revisando el script con todo lo aprendido. Estas son las correcciones que aplica la versión definitiva:

Los cambios respecto a la versión de 03-05:

• ${VELOZ_APP_LOG:?...} en las rutas obligatorias: si la configuración no las define, el script muere al instante con un mensaje claro en lugar de trabajar sobre rutas vacías. Y ${VELOZ_LOGS:-$HOME/veloz-ops/logs} en las opcionales, con valor por defecto sensato.
• ${2:?--fecha requiere un valor} dentro del case, que sustituye a la comprobación manual de 03-05 en una sola expresión.
• Comillas en absolutamente todas las expansiones, incluidas "$(date +%F)" y "$(grep -c ...)".
• printf en lugar de echo en toda la salida, con %q en los mensajes de error para que una opción con caracteres raros se vea tal cual llegó. En particular, printf '%s\n' "$lineas": si una línea del CSV empezara por -n o contuviera barras invertidas, echo podría interpretarla; printf '%s\n' nunca.

Ese último punto ilustra la mentalidad de la lección: no se trata de que el script falle hoy, sino de que no pueda fallar el día que aparezca un dato inesperado. Un printf en lugar de un echo cuesta cuatro caracteres y elimina una clase entera de bugs.

• No entrecomillar una variable. Rutas con espacios que se parten, variables vacías que desaparecen, globbing accidental. Es el error número uno.
• Usar comillas dobles en expresiones regulares o de awk. "$3" se expande a nada; usa comillas simples. Y no esperes que echo "\n" imprima un salto de línea: usa printf '\n'.
• Dejar un espacio después de la \ de continuación de línea. El comando se rompe y el error no lo indica.
• for f in $(ls). Usa globbing directo: for f in dir/*.
• Modificar IFS sin restaurarlo. Prefiere la forma IFS=',' read ..., que solo afecta a esa invocación.
• Confundir ${var:-x} con ${var:=x}. El primero no toca la variable; el segundo la asigna. Y no anides comillas invertidas: usa $( ), que anida sin escapes.

Ejercicio 1 — Predice la salida. Con ciudad="San Sebastián" y n=3, di exactamente qué imprime cada línea y por qué: (a) echo $ciudad; (b) echo "$ciudad"; (c) echo '$ciudad tiene $n letras'; (d) echo "$ciudad tiene ${#ciudad} letras"; (e) echo "Total: $(( n * 2 ))€".

Ejercicio 2 — Blindar un script peligroso. Este fragmento tiene seis problemas de comillas y expansión; encuéntralos y reescríbelo.

Ejercicio 3 — Informe alineado con printf. Lee envios.csv y produce una tabla con la ciudad alineada a la izquierda en 12 caracteres, el número de envíos a la derecha en 6, y el porcentaje sobre el total con una cifra decimal. Usa printf y expansión aritmética.

Solución al Ejercicio 1

El caso (a) es la trampa didáctica: con echo el resultado es idéntico al de (b), y por eso mucha gente concluye que las comillas son opcionales. Cambia echo por mkdir y (a) creará dos directorios.

Solución al Ejercicio 2

Los seis problemas: (1) $1 sin comillas ni validación; (2) comillas invertidas en lugar de $( ), dos veces; (3) for f in $(ls ...); (4) todas las variables de cp sin comillas; (5) $f contiene solo el nombre, no la ruta, así que el cp falla salvo que estés en ese directorio; (6) rm -rf $DIR_BACKUP/tmp/* sin comillas ni validación es una bomba, porque si $DIR_BACKUP está vacío se convierte en rm -rf /tmp/*.

La última línea merece atención especial: "${DIR_BACKUP:?}" es el idioma defensivo estándar antes de cualquier rm -rf, porque si la variable estuviera vacía el script aborta con un error en lugar de ejecutar un borrado catastrófico en la raíz. Cuesta cinco caracteres y ha salvado muchos servidores.

Solución al Ejercicio 3. Cuidado con una trampa: Bash no hace decimales (03-02), así que la parte entera y la decimal hay que calcularlas por separado.

La salida alinea las columnas: Valencia, 981, 78.6%; Bilbao, 148, 11.8%. Fíjate en tres cosas. El %% del formato imprime un porcentaje literal. El while read -r lee dos campos por línea, aprovechando que IFS divide por espacios exactamente donde uniq -c los deja. Y la aritmética entera obliga a esa gimnasia de multiplicar por 1000 y sacar el módulo; en 06-01 verás que awk hace lo mismo con printf "%.1f%%" y sin acrobacias.

Has cerrado el hueco que quedaba. Sabes en qué orden expande Bash una línea, y que la división en palabras ocurre después de sustituir las variables —el hecho del que se derivan casi todos los bugs de comillas—. Distingues con precisión qué expande cada tipo de comilla; entrecomillas toda variable por norma, sabiendo qué se rompe si no; escapas con \ sin caer en el espacio después de la continuación de línea; manejas ${var:-def}, ${var:=def}, ${var:?msg}, ${var:+val} y ${#var}; anidas $( ) sin escapes; entiendes IFS y lo cambias solo por invocación; has desterrado for f in $(ls) a favor del globbing directo; y usas printf cuando la salida debe ser predecible.

Y con eso termina el Módulo 3. Repasa el camino: empezaste guardando en un fichero las tuberías que tecleabas cada mañana, y informe-diario.sh es hoy un comando de ~/veloz-ops/bin con constantes, validación de entorno, códigos de salida documentados, opciones --fecha y --ciudad, --help, configuración por variables de entorno y expansiones blindadas. Ha crecido en seis lecciones sin que ninguna versión rompiera la anterior, que es exactamente como crece el software real. Sus límites, eso sí, se ven a simple vista: el script repite la misma tubería con pequeñas variaciones, si quisieras el informe de cada ciudad tendrías que invocarlo cuatro veces a mano, y no hay forma de reutilizar en otro script la lógica de validación que tanto te ha costado escribir.

En el Módulo 4 llegan las herramientas que resuelven eso. Los bucles (04-01) recorrerán ciudades, fechas y ficheros; las funciones (04-02) empaquetarán la validación y el formato para reutilizarlos; los arrays (04-03) guardarán listas de repartidores y contadores por ciudad; la manipulación de cadenas (04-04) completará la familia ${var...} que has empezado hoy; case (04-05) recibirá el tratamiento formal que aquí solo has usado de pasada; y la aritmética (04-06) resolverá de una vez esos porcentajes con decimales. informe-diario.sh dejará de ser un guion lineal para convertirse en un programa con estructura.