Prácticas seguras y defensivas para scripts Bash

Bash es una herramienta poderosa; con esa potencia viene responsabilidad. El código descuidado o mal planificado puede causar daños reales. Por eso conviene aplicar programación defensiva: reducir la probabilidad de errores, mejorar la depuración y manejar casos límite con claridad.

Bash ofrece mecanismos internos y prácticas de estilo que sustituyen métodos antiguos y problemáticos. Este artículo traduce esos mecanismos en reglas prácticas, ejemplos y procedimientos que puedes aplicar hoy.

Contenido

• Introducción y por qué importa
• Shebang: elegir la línea inicial adecuada
• Citar siempre variables
• Detener el script ante errores
• Manejar fallos y propagar errores
• Depurar cada comando con xtrace
• Usar parámetros largos para mayor claridad
• Sustitución de comandos moderna
• Valores por defecto y anidamiento
• Doble guion para separar opciones y argumentos
• Variables locales en funciones
• Contratiempos comunes y cómo fallan las prácticas
• Alternativas y herramientas auxiliares
• Mini-metodología y flujo de decisiones
• Listas de verificación por rol
• Playbook de incidentes y rollback
• Casos de prueba y criterios de aceptación
• Snippets y hoja de trucos
• Glosario de una línea
• Resumen final

Introducción y por qué importa

Los scripts Bash suelen automatizar tareas de administración, despliegues y transformaciones de datos. Un error puede borrar archivos, exponer secretos o detener servicios. Muchas fallas provienen de supuestos implícitos: rutas estáticas, suposiciones sobre el entorno, variables no inicializadas o nombres de archivos con espacios o caracteres extraños.

Objetivo: reducir la superficie de fallo. Aplicar principios sencillos y consistentes hace que los scripts sean más robustos, más fáciles de leer y más seguros.

Nota importante: este contenido no pretende sustituir revisiones de seguridad ni pruebas en entornos controlados. Aplica cada práctica y prueba en un entorno de desarrollo antes de usar en producción.

Shebang: elegir la línea inicial adecuada

La primera línea de un script debe declarar el intérprete con una hembang (shebang). Esto hace el script autónomo y explícito sobre el lenguaje en uso.

Dos enfoques comunes:

• Ruta fija, por ejemplo /bin/bash — garantiza el ejecutable específico.
• env + nombre del comando, por ejemplo /usr/bin/env bash — respeta el PATH del usuario y suele ser más portable.

Ejemplos:

#!/bin/bash
echo "Hello, world"

#!/usr/bin/env bash
echo "Hello, world"

Comparación práctica:

• /bin/bash: es determinista. Útil cuando controlas el entorno de ejecución y necesitas garantizar una versión específica.
• /usr/bin/env bash: es portable. Útil cuando los usuarios pueden tener Bash en distintas rutas (por ejemplo, en /usr/local/bin o en entornos virtuales).

Recomendación: para scripts de uso general o compartidos, usa /usr/bin/env bash por portabilidad. Para scripts que se ejecutan en sistemas controlados (controles estrictos de versiones), usar la ruta fija puede ser más seguro.

Citar siempre variables

El manejo del espacio en blanco es la principal fuente de problemas en shells. Cuando Bash expande variables, lo hace literalmente. Por eso las variables deben ir entre comillas.

Ejemplo peligroso:

#!/bin/bash

FILENAME="docs/Letter to bank.doc"
ls $FILENAME

Expansión resultante (peligrosa):

ls docs/Letter to bank.doc

Bash interpreta espacios como separadores de argumentos, por tanto se pasan varios argumentos a ls en lugar de uno.

Solución:

ls "$FILENAME"

Consejo: usa llaves cuando añadas texto literal junto a la variable:

echo "_${FILENAME}_ es uno de mis archivos favoritos"

Sin llaves, Bash interpretaría una variable llamada FILENAME_ y fallaría.

Detener el script ante errores

No ignores fallos. Un script que continúa tras un error suele ampliar el daño. Usa set -e para que el script salga cuando un comando retorne un estado distinto de cero.

set -e

Definición práctica: si alguna orden falla y no ha sido capturada, el script se detendrá inmediatamente.

Ejemplo problemático:

#!/bin/bash

touch /file
echo "Ahora haga algo con ese archivo..."

Si touch falla, sin set -e el script continúa. Con set -e, el script se detiene y evita efectos en cascada.

Complementa esto con:

set -o pipefail

pipefail hace que la tubería falle si cualquier componente falla. Por defecto, el fallo en un comando intermedio puede quedar oculto.

Manejar fallos y propagar errores

Set -e es un amortiguador. Aun así, maneja errores explícitamente cuando necesites acciones concretas.

Comprobar el estado de salida:

cd "$DIR"
if [ $? -ne 0 ]; then
  exit 1
fi

Forma corta con operadores lógicos:

cd "$DIR" || { echo "Error al cambiar de directorio"; exit 1; }

Consejo: usa agrupación con llaves { } en lugar de paréntesis (que ejecutan subshell) para que cualquier cambio de variable afecte al entorno actual.

Depurar cada comando con xtrace

Para depuración activa, habilita xtrace:

set -o xtrace
# o
set -x

Esto hace que el intérprete imprima cada comando antes de ejecutarlo, mostrando la expansión de variables y la secuencia exacta. Muy útil para localizar dónde fallan las expansiones o qué argumentos se pasan realmente.

Consejo práctico: activa xtrace condicionalmente cuando pases una opción –debug al script. Ejemplo:

if [ "${DEBUG:-}" = "1" ]; then
  set -x
fi

De este modo solo verás trazas cuando lo necesites.

Usar parámetros largos para mayor claridad

Los comandos Unix tienden a usar opciones de una sola letra. En scripts destinados a otras personas, favorece las opciones largas por legibilidad.

Ejemplo corto y menos legible:

rm -rf filename

Mejor y más explícito:

rm --recursive --force filename

Las opciones largas (–opcion) no se combinan, pero son autoexplicativas. En scripts compartidos, favorecen la mantenibilidad y reducen la posibilidad de errores de interpretación.

Sustitución de comandos moderna

Para capturar la salida de un comando, usa la sintaxis $(comando) en lugar de acentos graves comando.

Ejemplo moderno y preferible:

VAR=$(ls)

Sintaxis antigua (no recomendada):

VAR=`ls`

La sintaxis con $() permite anidar llamadas y es más legible.

Declarar valores por defecto

Puedes definir valores por defecto con la forma ${VAR:-default}. Esto evita comprobaciones adicionales en el código.

Ejemplo:

CMD=${PAGER:-more}

Si PAGER está definido, CMD toma ese valor; si no, usa more.

Anidamiento:

DIR=${1:-${HOME:-/home/usuario}}

Esto respeta el primer argumento, luego la variable de entorno HOME y, finalmente, un valor por defecto.

Nota: evita usar valores por defecto para datos sensibles sin validarlos antes.

Doble guion para separar opciones y argumentos

Un nombre de archivo que comienza por “-“ puede confundirse con una opción. El doble guion – le dice al comando que todo lo que sigue son argumentos, no opciones.

Ejemplo peligroso:

echo "nada importante" > -a-silly-filename
rm *

Si existe un archivo llamado “-rf”, rm * podría interpretar esa entrada como opciones y causar problemas.

Solución:

rm -- *.md

Recomendación: combina buenas prácticas de nombres de archivo (minúsculas y sin caracteres especiales) con defensas en el script (usar – y validaciones).

Variables locales en funciones

En Bash, las variables son globales por defecto. Dentro de funciones, declara variables como locales para evitar efectos colaterales:

Ejemplo problemático:

#!/bin/bash

function run {
  DIR=`pwd`
  echo "haciendo algo..."
}

DIR="/usr/local/bin"
run
echo $DIR

Aquí run cambia DIR globalmente. Solución:

function run {
  local DIR=$(pwd)
  echo "haciendo algo..."
}

Usa local con cuidado: funciona en Bash, pero en shells más antiguos puede no estar disponible.

Contratiempos comunes y ejemplos de fallos

1. Espacios y expansión incompleta

• Problema: usar $VAR sin comillas. Resultado: múltiples argumentos inesperados.
• Solución: siempre “${VAR}”.

2. Falso positivo por tuberías

• Problema: comando1 | comando2; el fallo de comando1 puede pasar desapercibido.
• Solución: set -o pipefail.

3. Uso de eval

• Problema: eval ejecuta texto como comandos; es una fuente frecuente de inyección.
• Solución: evitar eval; usar arrays y parámetros seguros.

4. Variables no inicializadas

• Problema: usar variables sin verificar conduce a comportamientos impredecibles.
• Solución: set -u para tratar variables no definidas como error, y proporcionar valores por defecto.

Ejemplo de combinación útil:

set -euo pipefail
IFS=$'\n\t'

Explicación:

• -e detiene en errores
• -u falla en variables no definidas
• -o pipefail asegura fallo en tuberías
• IFS se reduce para evitar recortes inesperados por espacios

Advertencia: set -u puede romper scripts que dependen de variables opcionales; usa con previsión.

Herramientas y alternativas

• ShellCheck: analizador estático para scripts shell. Detecta errores comunes y ofrece sugerencias.
• shfmt: formateador que mejora consistencia y legibilidad.
• bash -n script.sh: comprueba la sintaxis sin ejecutar.
• bats-core: framework de pruebas para scripts shell.

Combina estas herramientas en tu CI para detectar problemas antes del despliegue.

Mini-metodología: cómo escribir un script Bash robusto (paso a paso)

1. Definir objetivo claro y casos de uso.
2. Escribir pruebas mínimas con bats o scripts de integración.
3. Empezar con shebang claro (/usr/bin/env bash) salvo que se requiera ruta fija.
4. Añadir: set -euo pipefail e IFS seguro.
5. Citar todas las variables.
6. Validar entradas y sanear nombres de archivo.
7. Evitar eval y construcciones inseguras.
8. Añadir opciones –help y –debug.
9. Formatear con shfmt y comprobar con ShellCheck.
10. Probar en entornos de staging antes de producción.

Flujo de decisiones (Mermaid)

graph TD
  A[¿Script para uso local?] -->|Sí| B[Usar /bin/bash o /usr/bin/env según preferencias]
  A -->|No| C[Usar /usr/bin/env bash]
  B --> D{¿Requiere versión específica?}
  D -->|Sí| E[/bin/bash]
  D -->|No| F[/usr/bin/env bash]
  C --> G[Aplicar set -euo pipefail]
  E --> G
  F --> G
  G --> H[Agregar tests y ShellCheck]
  H --> I[Desplegar en staging]
  I --> J[Revisión y monitoreo]

Listas de verificación por rol

Checklist para desarrolladores:

• Shebang apropiado
• set -euo pipefail y IFS seguro
• Todas las variables están citadas
• No se usa eval
• Valores por defecto definidos
• Opciones largas en comandos críticos
• Tests unitarios con bats
• ShellCheck y shfmt pasan

Checklist para operaciones / SRE:

• Revisión de permisos y propietarios
• Pruebas en staging replicando entorno prod
• Backups antes de despliegues automáticos
• Monitorización y alertas para scripts críticos
• Procedimiento de rollback documentado

Checklist para revisores de código:

• Claridad y comentarios suficientes
• Variables locales en funciones
• Manejo explícito de errores
• Evitar efectos colaterales globales
• Validación de entradas externas

Playbook de incidentes y rollback

Este playbook es un procedimiento simple cuando un script automático daña datos o interrumpe servicios.

Paso 0: No ejecutar comandos adicionales que alteren el estado hasta tener un plan.

1. Identificar alcance
   • ¿Qué script? ¿Qué hosts? ¿Qué usuarios? Recolecta logs.
2. Poner en pausa ejecuciones automáticas
   • Detén cron, systemd timers o jobs programados.
3. Hacer snapshot o backup inmediato del sistema afectado
   • Si hay soporte de snapshot (VM, contenedor o almacenamiento), crear snapshot.
4. Determinar punto de restauración seguro
   • ¿Existe backup reciente, imagen o dump?
5. Restauración mínima
   • Recuperar solo lo imprescindible para restaurar el servicio.
6. Ejecutar postmortem
   • Anotar la causa raíz, añadir tests que prevengan la regresión y revisar el proceso de despliegue.
7. Actualizar el script
   • Añadir protecciones: comprobaciones, set -euo pipefail, validaciones y pruebas automáticas.
8. Reincorporar automatización con cautela
   • Desplegar en staging, revisar logs y habilitar gradualmente.

Rollback técnico (cuando procede):

• Si el daño fue sobre datos, restaurar desde backup más reciente. Si no hay backup reciente, aislar y detener el servicio para evitar más corrupción.
• Si el daño fue por eliminación de archivos, no reescribir el FS; usar herramientas de recuperación o restaurar desde backup.

Casos de prueba y criterios de aceptación

Casos mínimos a incluir en la suite de pruebas de cualquier script:

1. Argumentos válidos
   • Entrada: argumentos correctos
   • Resultado esperado: salida correcta, código 0
2. Argumentos faltantes
   • Entrada: sin argumentos donde se necesitan
   • Resultado esperado: mensaje de ayuda y código distinto de 0
3. Nombres de archivo con espacios
   • Entrada: archivos con espacios y caracteres especiales
   • Resultado esperado: operaciones correctas sobre archivos
4. Falla de comando externo
   • Forzar fallo (por ejemplo, chmod denegado)
   • Resultado esperado: script detiene o maneja el error según especificado
5. Ejecución en entorno con PATH alternativo
   • Resultado esperado: comportamiento coherente con shebang elegido

Criterios de aceptación:

• ShellCheck no debe reportar advertencias clasificadas como errores.
• Tests pasan en CI y en un entorno de staging que reproduce producción.
• El script debe cubrir mensajes de error útiles y manejables.

Snippets y hoja de trucos

Plantilla mínima para scripts robustos:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Nombre: ejemplo.sh
# Uso: ejemplo.sh [opciones]

usage() {
  cat <

Ejemplo de lectura segura de argumentos con getopts para opciones cortas y getopt para largas:

PARSED=$(getopt --options "d" --long "debug,help" -- "$@")
if [ $? -ne 0 ]; then
  usage
  exit 2
fi
eval set -- "$PARSED"
while true; do
  case "$1" in
    -d|--debug)
      DEBUG=1; shift ;;
    --help)
      usage; exit 0 ;;
    --)
      shift; break ;;
    *)
      break ;;
  esac
done

Evitar eval para construir comandos dinámicos: usa arrays.

cmd=(ls -l)
cmd+=("--color=auto")
"${cmd[@]}"

Esto preserva espacios y evita inyección.

Comparación breve: /bin/bash vs /usr/bin/env bash

• Portabilidad: /usr/bin/env gana.
• Determinismo: /bin/bash gana.
• Seguridad contra PATH maliciosos: /bin/bash gana si confías en la ubicación.

Decisión: para scripts que se distribuyen ampliamente, prioriza portabilidad. Para control total del entorno, prioriza determinismo.

Seguridad y endurecimiento

Buenas prácticas de seguridad:

• No ejecutes scripts como root salvo que sea imprescindible. Si necesitas privilegios, ejecuta pasos puntuales con sudo y valida entradas.
• Evita eval y construcciones que ejecuten texto no confiable.
• Usa permisos mínimos en archivos y scripts (700 para scripts personales, 750 o 755 según el caso).
• Revisa variables de entorno que afecten comportamiento (PATH, LD_LIBRARY_PATH) y no asumas que son seguras.
• Si trabajas con datos sensibles, limita la salida de logs y protege los ficheros de configuración (chmod 600).

Plantillas útiles

Plantilla de validación de entorno:

require_command() {
  command -v "$1" >/dev/null 2>&1 || { echo "Se requiere $1" >&2; exit 1; }
}

require_command bash
require_command ls

Plantilla para manejo de archivos temporales segura:

tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT

Glosario de una línea

• shebang: línea inicial que indica el intérprete.
• xtrace: opción que muestra comandos antes de ejecutarlos (set -x).
• pipefail: opción que falla la tubería si algún comando falla.
• IFS: Internal Field Separator, separador interno de campos.
• eval: ejecuta texto como código (evitar si es posible).

Contrapuntos y cuándo estas prácticas pueden fallar

• set -e puede ocultar errores si el script pretende capturar salidas no críticas; en esos casos maneja errores explícitamente.
• set -u rompe scripts que usan variables opcionales sin comprobación; añade validaciones o valores por defecto.
• Declarar todo local puede no funcionar en shells mínimos que ejecuten sh en vez de bash.
• getopts estándar no soporta opciones largas; para opciones largas usa getopt o parseo manual.

Sugerencias de vista social y anuncio

OG title sugerido: Prácticas seguras para scripts Bash OG description sugerido: Guía práctica con ejemplos, playbook de incidentes y plantillas para escribir scripts Bash robustos y fáciles de mantener.

Versión corta de anuncio (100–200 palabras):

Aprende a escribir scripts Bash más seguros y fiables. Esta guía práctica cubre desde la línea shebang hasta cómo manejar errores, depurar con xtrace y proteger archivos con doble guion. Incluye plantillas, listas de verificación por rol, un playbook de incidentes y fragmentos reutilizables. Ideal para administradores, desarrolladores y SREs que quieren reducir riesgos en automatizaciones.

Resumen final

• Usa un shebang claro y elige entre portabilidad y determinismo según el contexto.
• Cita siempre variables y usa llaves cuando añadas texto literal.
• Activa set -euo pipefail e IFS seguro para robustez por defecto.
• Evita eval y construye comandos con arrays para prevenir inyección.
• Añade tests, formatea y comprueba con ShellCheck y shfmt antes de desplegar.

Fin. Sigue estas prácticas y reduce drásticamente la probabilidad de errores graves en tus scripts Bash.