revision_salud.sh ya lee su configuración del entorno, pero sigue siendo un botón de una sola posición: no sabe explicarse, no admite «esta vez usa umbral 60» sin exportar una variable, y no hay forma de pedirle que calle. Un script sin interfaz es un script que solo puede usar quien lo escribió, y esta lección le da esa interfaz. Vas a aprender por dónde entra la información en un script y por dónde debe salir, y las dos preguntas tienen respuestas muy concretas: argumentos para lo que cambia en cada ejecución, stdin para los datos, stdout para el resultado y stderr para el humano. Esa disciplina es lo que hace que un programa sea componible, que encaje en una tubería como encajan grep o sort. Al final tendrás revision_salud.sh con opciones de verdad y nacerá informe_reservas.sh.

1. Los cuatro canales de entrada
2. Parámetros posicionales
3. $@ frente a $*: la diferencia que causa más bugs
4. Validar argumentos y la función de ayuda
5. Opciones: parseo manual y getopts
6. Convenciones de línea de comandos
7. read: leer del usuario y de un fichero
8. Salida: stdout para el resultado, stderr para el humano
9. Códigos de salida con significado
10. Ficheros de configuración y el modo --dry-run
11. Aplicación: opciones en revision_salud.sh y nace informe_reservas.sh

Un script puede recibir información por cuatro vías, y elegir mal es la primera decisión de diseño que se estropea.

La regla de precedencia del curso, de más fuerte a más débil: argumentos > entorno > fichero de configuración > valores por defecto. Es la que espera cualquier administrador: permite fijar lo estable en un fichero y saltárselo puntualmente desde la línea de comandos.

Al invocar script.sh alfa beta, Bash rellena un conjunto de variables especiales:

shift descarta el primer argumento y desplaza el resto: $2 pasa a ser $1 y $# decrece; shift N descarta N de golpe. Es el mecanismo básico de cualquier bucle de parseo. ${0##*/} —expansión de parámetros de 04-02— da el nombre sin ruta, que es lo que quieres en la ayuda. Y puedes reasignar los posicionales con set -- "${@:-08}" para aplicar un valor por defecto; el -- es imprescindible, porque sin él set tomaría por opción suya cualquier argumento que empiece por -.

Igual que con los arrays en 04-02, la diferencia solo aparece dentro de comillas dobles, y ahí se rompen los scripts en cuanto alguien pasa un nombre con espacios.

"$@" es la única forma correcta de reenviar los argumentos a otro comando: produce exactamente los mismos que recibiste, con sus espacios intactos. "$*" los une en una cadena separada por el primer carácter de IFS y solo sirve para imprimir. Sin comillas, ambos se parten y «informe agosto.txt» se convierte en dos ficheros inexistentes. La regla, sin excepciones: "$@" para pasar, "$*" para mostrar.

Un script serio comprueba lo que recibe antes de hacer nada, y sabe explicarse:

Fíjate en un detalle que casi nadie hace bien y que separa a un script educado de uno maleducado: si el usuario pide ayuda con -h, la ayuda es el resultado y va a stdout con código 0; si se muestra porque se ha equivocado, es un mensaje de error y va a stderr con código distinto de 0. La diferencia importa: script.sh -h | less funciona en el primer caso, y script.sh 2>/dev/null no silencia el resultado legítimo en el segundo. El cat <<EOF es el here-document de 03-04: sin comillas en EOF, ${0##*/} se expande.

Única forma de admitir opciones largas (--umbral) en Bash puro, y el patrón es siempre el mismo:

Cada rama consume lo suyo con shift (uno si es un interruptor, dos si lleva valor) y el bucle vuelve a empezar. --umbral=60 se resuelve con ${1#*=}, que recorta hasta el primer =; -- marca el fin de opciones; lo que empiece por - y no reconozcas es un error de uso, y cualquier otra cosa es el primer posicional y termina el parseo. (case se formaliza en 04-04.)

Cuando te bastan las cortas, getopts es un builtin que hace todo el trabajo, incluido agrupar -vn como -v -n:

Cuatro piezas hay que entender:

• La cadena ":hvu:". Cada letra es una opción; los dos puntos detrás de una letra (u:) significan «esta lleva valor».
• Los dos puntos iniciales. Activan el modo silencioso: getopts deja de imprimir sus mensajes en inglés y te avisa con \? (opción desconocida) y : (falta el valor), poniendo la letra culpable en OPTARG. Ponlos siempre, o tu script mezclará mensajes suyos con mensajes de Bash.
• OPTARG contiene el valor de la opción actual, y OPTIND el índice del siguiente argumento por procesar. El shift $(( OPTIND - 1 )) final descarta las opciones consumidas y deja en $1 el primer posicional real. Si olvidas esa línea, $1 seguirá siendo -v.

Existe además getopt (sin s, el programa externo de GNU), que sí admite opciones largas reordenando los argumentos, pero su sintaxis con eval set -- "$OPCIONES" es frágil y la versión de macOS no es compatible. Resumiendo: getopts si te bastan las cortas, parseo manual si necesitas las largas, y getopt solo si sabes exactamente lo que haces.

Respetarlas es lo que hace que otra persona pueda usar tu script sin leerlo.

read toma una línea de stdin y la reparte en variables. Sus opciones útiles:

Ese -s es la forma correcta de pedir un secreto de forma interactiva: no queda en pantalla ni en el historial. En 04-07 veremos la alternativa para tareas desatendidas.

while IFS= read -r linea; do ... done < fichero es de las líneas que conviene memorizar tal cual, porque cada pieza está ahí por un motivo concreto:

• IFS= (vacío, y solo para este read) impide que Bash recorte los espacios del principio y del final; sin él, la indentación de un fichero de configuración desaparece. -r impide que las barras invertidas se interpreten como escapes, y < fichero al final del done —no una tubería— es lo importante, como vemos ahora.

Ha recorrido 87 líneas y el contador vale 0. La razón la conoces desde 04-02: cada tramo de una tubería se ejecuta en un subshell, así que el while incrementó su copia y esa copia murió al cerrarse la tubería. El mismo muro del cd, disfrazado. Tres soluciones, en orden de preferencia:

La 2 es la que más usarás. La 3 tiene letra pequeña: lastpipe solo funciona con el control de trabajos desactivado, cosa que ocurre en un script no interactivo pero no en tu terminal, así que probarlo a mano puede engañarte.

La regla que convierte un script en una pieza de Unix: stdout es el resultado —lo que otro programa podría querer procesar, datos y solo datos— y stderr es todo lo demás: avisos, progreso, errores, mensajes de -v. Si los mezclas, mi_script.sh | awk '{...}' se atraganta con tu «Procesando...» y mi_script.sh > informe.txt deja los errores dentro del informe. Las dos funciones que garantizan la disciplina:

Los mensajes han aparecido en la terminal y el fichero solo contiene el dato: eso es un script componible. Usamos printf en lugar de echo por la razón de 04-02: comportamiento definido y formato controlado.

Con la interfaz montada, el código de salida deja de ser «0 o 1» y pasa a ser documentación ejecutable. La convención de Tramontana toma prestados los valores de sysexits.h:

Lo esencial no es adoptar exactamente estos números, sino elegir unos, documentarlos en la cabecera y ser coherente: un script cuyo 69 significa siempre «la aplicación no responde» permite que quien lo llama actúe sin leer su salida.

Hay dos formas de leer un fichero de configuración, y una es peligrosa. source /etc/tramontana/app.conf es cómoda, pero el fichero es código que se ejecuta con tus permisos: si alguien con escritura sobre él añade rm -rf /, tu script lo ejecuta. Es el mismo riesgo que dejó una credencial expuesta en una copia con permisos 644. Con source solo se puede vivir si el fichero es tuyo, con permisos estrictos y verificados. La alternativa segura es parsearlo:

Solo se aceptan las claves que el script conoce. Es más código, pero es la diferencia entre leer datos y ejecutar código ajeno.

El modo --dry-run es el otro patrón imprescindible, y se implementa con un envoltorio:

"$@" dentro de ejecutar reconstruye el comando con sus argumentos exactos —de ahí que el apartado 3 importara tanto— y con DRY_RUN=1 solo lo imprime. La regla de 03-03 se vuelve así automática: todo script que borre, mueva o sobrescriba algo tiene --dry-run.

La cabecera de revision_salud.sh pasa a documentar la sintaxis y los códigos (# Uso: revision_salud.sh [-h] [-v] [-u UMBRAL], # Salida: 0 correcto | 2 uso incorrecto), y entre la configuración de 04-02 y el cuerpo se intercala esto:

UMBRAL_DISCO ya no puede ser readonly: la opción -u debe sobrescribir el valor del entorno, que a su vez sobrescribe el defecto. Es la precedencia del apartado 1, implementada.

El resultado fue al fichero y la traza a la terminal, tal como promete el apartado 8. Y fíjate en el return 0 de log(): sin él, cuando VERBOSE vale 0 la función devuelve 1 y con set -e el script moriría en la primera llamada; es una de las trampas que 04-06 desmenuza. Vamos con el script nuevo que Marta pidió para su informe mensual:

Dos detalles de diseño: : "${SALIDA:=...}" usa el builtin : (que no hace nada) solo para forzar la asignación por defecto ${VAR:=valor} de 04-02, y el script imprime la ruta por stdout, de modo que ruta=$(...) la captura y el informe queda listo para encadenar con mail o scp.

• Olvidar shift $(( OPTIND - 1 )). El fallo número uno con getopts: las opciones siguen ocupando $1 y el script cree que le faltan argumentos. El segundo es usar $@ o $* sin comillas, con lo que cualquier argumento con espacios se parte.
• read sin -r. Una ruta con \ se corrompe silenciosamente; no hay ningún caso en que quieras read sin -r. Y evita los bucles while read al final de una tubería: las variables mueren con el subshell, así que usa < fichero o < <(comando).
• Mandar los mensajes de progreso a stdout. Contaminas el resultado y rompes cualquier tubería: todo lo que no sea el dato va a stderr. Y getopts sin los dos puntos iniciales hace que tu script imprima mensajes en inglés que no controlas.
• Poner un secreto en la línea de comandos. Cualquiera con acceso a ps lo ve, y queda en ~/.bash_history. Fichero con permisos 600 o variable de entorno; lo cerramos en 04-07 y en 06-05.
• Consejo: escribe la función uso() antes que el cuerpo; si te cuesta describir la interfaz, es que aún no la has decidido. Y haz que -h funcione siempre, incluso sin argumentos y sin configuración válida: es lo primero que prueba quien encuentra tu script.
• Consejo: valida los argumentos en cuanto los tengas y sal inmediatamente si algo no cuadra. Cuanto antes falle, menos ha destrozado.

Ejercicio 1. Escribe ~/scripts/contar_errores.sh, que lea por stdin un log con el formato de acceso.log y acepte -c CODIGO (por defecto 500), -v y -h. Debe imprimir por stdout solo el número de líneas con ese código y, con -v, cuántas líneas leyó en total por stderr. acceso.log tiene 412 líneas y 14 respuestas 500.

Ejercicio 2. Amplía informe_reservas.sh con -n/--dry-run, que muestre qué fichero se escribiría sin crearlo, usando el envoltorio ejecutar(). Explica por qué el parseo tiene que pasar de getopts a manual.

Ejercicio 3. Luis ha escrito esto para contar cuántas IP distintas hay en acceso.log y dice que «devuelve 0 siempre, será cosa del log»: n=0; cut -d' ' -f6 acceso.log | sort -u | while read ip; do n=$((n+1)); done; echo "$n". Diagnostícalo y da dos soluciones.

Solución 1. Cabecera y getopts como en los apartados 4 y 5, con ":hvc:" y CODIGO="$OPTARG". Lo interesante es el cuerpo:

read con varios nombres trocea la línea por IFS sin llamar a cut ni a awk: 412 procesos ahorrados. Aquí sí omitimos IFS=, porque queremos precisamente la división en campos.

Solución 2. Hay que pasar a parseo manual porque getopts no admite opciones largas: --dry-run llegaría entera y getopts la leería como -, -d, -r… Se sustituye el while getopts por el bucle while [[ $# -gt 0 ]] del apartado 5, añadiendo la rama -n|--dry-run) DRY_RUN=1; shift ;;, y el envoltorio hace el resto:

El directorio sigue vacío: nada se ha creado. Y nota que la redirección > "$SALIDA" no puede pasar por ejecutar, porque el shell la resuelve antes de invocar la función; de ahí que ese caso lleve su propio if. Es la limitación clásica del patrón.

Solución 3. El diagnóstico: while read es el último tramo de una tubería, así que corre en un subshell; n se incrementa en la copia y el echo del shell principal ve el 0 original. No tiene nada que ver con el log.

Las cinco IP conocidas (10.0.2.77, .31, .44, .52 y .18). Prefiere la B: si el bucle solo cuenta, no necesitas el bucle. Un tercer camino sería shopt -s lastpipe, pero en tu terminal interactiva no funciona y podrías creer que tu arreglo no sirve.

Tus scripts ya tienen interfaz, y con ella dejan de ser tuyos para ser utilizables.

• Distingues los cuatro canales de entrada y aplicas la precedencia argumentos > entorno > configuración > defectos.
• Manejas los parámetros posicionales con $#, shift, ${10} y set --, y sabes que "$@" es la única forma correcta de reenviar argumentos mientras que "$*" solo sirve para mostrar.
• Escribes una función uso() que va a stdout si la piden y a stderr si es un error, y parseas opciones con getopts —cadena de opciones, dos puntos iniciales, OPTARG y el imprescindible shift $(( OPTIND - 1 ))— o a mano con while y case para las largas, respetando las convenciones -h, -v, -q, -n y --.
• Usas read con -r siempre, y conoces el patrón canónico while IFS= read -r linea; do ... done < fichero, con las tres soluciones al bucle que pierde las variables por el subshell.
• Separas stdout (el resultado) de stderr (el humano) con log() y error(), devuelves códigos de salida documentados, lees configuración parseándola en vez de con source, y llevas --dry-run incorporado con el envoltorio ejecutar().

Pero mira el código que has escrito hoy: está lleno de if, de case y de [[ ]] usados por intuición, sin haberlos estudiado. Es el momento de arreglarlo. En Estructuras de Control verás la idea que sostiene todo Bash —que se ramifica según el código de salida de un comando, no según un booleano—, los tres tipos de test y cuándo usar cada uno, la tabla completa de operadores de fichero, cadena y número, =~ con BASH_REMATCH para validar fechas, case con sus patrones y sus tres terminadores, todos los bucles con la advertencia de por qué nunca for f in $(ls), y una medición real sobre acceso.log que te dirá cuándo un bucle de Bash es mil veces más lento que un awk. Al terminarla, revision_salud.sh sabrá decir OK, AVISO o CRÍTICO, y purgar_releases.sh recorrerá /opt/tramontana/releases/ sin tocar la versión activa.