El método infalible para lanzar un script desde otro script en Bash

¡Hola, intrépidos exploradores del mundo Bash! 👋 Hoy nos embarcamos en una aventura que, aunque parezca sencilla a primera vista, esconde matices cruciales para cualquier desarrollador, administrador de sistemas o entusiasta de la automatización. Hablamos de la venerable tarea de ejecutar un script desde otro script. Una necesidad tan fundamental como respirar en el universo de la línea de comandos, pero que a menudo nos lleva a rascar la cabeza cuando los resultados no son los esperados.

¿Te has encontrado alguna vez con la frustración de que un script secundario no comparte las variables de entorno de su invocador? ¿O que un error en el script llamado detiene todo el proceso de manera inesperada? No te preocupes, no estás solo. Este artículo es tu guía definitiva, tu mapa del tesoro, para dominar esta técnica y transformar tus flujos de trabajo en verdaderas sinfonías de automatización. Vamos a desglosar los métodos, sus secretos, sus pros y sus contras, y a construir un arsenal de conocimiento que hará que tus scripts actúen como un equipo perfectamente coordinado. ¡Prepárate para llevar tus habilidades de scripting al siguiente nivel! 🚀

¿Por Qué Necesitamos Lanzar un Script Desde Otro? La Base de la Automatización ⚙️

La modularidad es la piedra angular de cualquier sistema bien diseñado. Imagina tener un script gigante que se encarga de todo: limpiar logs, hacer copias de seguridad, desplegar aplicaciones, enviar notificaciones… Sería una pesadilla de mantener, depurar y escalar. Aquí es donde entra en juego la orquestación de scripts.

Al dividir tareas complejas en scripts más pequeños y especializados, conseguimos:

• Organización y Claridad: Cada script tiene una responsabilidad única y bien definida.
• Reutilización: Un script para „notificar error” puede ser invocado desde múltiples procesos.
• Mantenibilidad: Cambiar una función específica no requiere modificar el script principal entero.
• Depuración Simplificada: Aislar problemas es mucho más fácil cuando cada componente es independiente.

Pero, ¿cómo nos aseguramos de que estos componentes hablen entre sí de la manera correcta? Esa es la pregunta del millón, y la respuesta está en comprender los distintos métodos de invocación.

Los Fundamentos: Métodos Clásicos de Invocación

Existen tres formas principales de lanzar un script desde otro en Bash, y cada una tiene su propio comportamiento y casos de uso específicos. Ignorar estas diferencias es la receta para la frustración. ¡Vamos a explorarlas!

1. Ejecución Directa: El Enfoque del Subproceso 🚀

Esta es probablemente la forma más común y la que la mayoría de nosotros utilizamos instintivamente. Simplemente llamas al script como si lo ejecutaras desde la línea de comandos:

./mi_otro_script.sh
bash mi_otro_script.sh
sh mi_otro_script.sh

¿Cómo funciona? 💡 Cuando utilizas este método, Bash crea un nuevo proceso, un „subshell”, para ejecutar mi_otro_script.sh. Este nuevo proceso es independiente de tu script principal. Es como si el script padre le dijera a su hijo: „Haz esto y avísame cuando termines”.

Implicaciones Clave:

• Entorno Aislado: Las variables de entorno (las que se exportan) se heredan, pero las variables locales y los alias definidos en el script principal *no* se comparten con el script invocado. Cualquier cambio que el script invocado haga en sus propias variables locales o en el directorio de trabajo *no* afectará al script padre.
• Control de Retorno: El script principal espera a que el subproceso termine. Puedes capturar el código de salida (status code) del script secundario usando $? justo después de su ejecución. Esto es fundamental para el manejo de errores.
• Modularidad por Defecto: Ofrece una excelente separación de preocupaciones, ya que los scripts operan en sus propios espacios.

Cuándo usarlo: Ideal cuando quieres que el script invocado sea una unidad de trabajo autónoma y no necesitas que comparta su estado interno con el script principal. Por ejemplo, un script que realiza una copia de seguridad o un despliegue, donde sus operaciones no deben interferir directamente con el entorno del script padre.

#!/bin/bash

# script_principal.sh
echo "Iniciando script principal..."
VARIABLE_PADRE="Valor del padre"
export VARIABLE_EXPORTADA="Exportado desde el padre"

echo "Lanzando script secundario..."
./script_secundario.sh "Argumento1" "Argumento2"

CODIGO_SALIDA=$?
echo "Script secundario finalizado con código: $CODIGO_SALIDA"

echo "La variable local del padre sigue siendo: $VARIABLE_PADRE"
echo "Directorio de trabajo actual: $(pwd)"

#!/bin/bash

# script_secundario.sh
echo "  Dentro del script secundario..."
echo "  Argumentos recibidos: $@"
echo "  Variable exportada recibida: $VARIABLE_EXPORTADA"

VARIABLE_HIJO="Valor del hijo"
echo "  Definiendo variable local en el hijo: $VARIABLE_HIJO"
cd /tmp # Cambiando directorio en el hijo
echo "  Nuevo directorio de trabajo en el hijo: $(pwd)"

# Simulando un fallo o éxito
if [ "$1" == "fallo" ]; then
    exit 1 # Fallo
else
    exit 0 # Éxito
fi

2. El Comando source (o su alias .): ¡Compartiendo el Mismo Espacio! 🤝

A diferencia de la ejecución directa, el comando source (o su forma abreviada .) no crea un nuevo subproceso. En cambio, ejecuta el script proporcionado dentro del contexto del script actual.

source mi_otro_script.sh
. mi_otro_script.sh

¿Cómo funciona? 💡 Piensa en source como si Bash copiara y pegara el contenido del script secundario directamente en el lugar donde lo invocaste en el script principal. Todas las variables, funciones, alias y cambios de directorio definidos en el script secundario se convierten en parte del entorno del script principal.

Implicaciones Clave:

• Entorno Compartido: Todas las variables (locales o exportadas), funciones y alias definidos en el script invocado estarán disponibles y serán modificables por el script principal (y viceversa). ¡Esto es una espada de doble filo! ⚠️
• Cambios Persistentes: Si el script „sourced” cambia el directorio de trabajo (cd), ese cambio persistirá en el script principal.
• No Hay Nuevo Proceso: No se genera un nuevo PID (Process ID) para el script invocado.

Cuándo usarlo: Perfecto para cargar archivos de configuración (.bashrc, .profile), bibliotecas de funciones o módulos de variables que necesitas que estén disponibles y sean compartidos por el script principal. Es excelente para construir scripts con componentes altamente acoplados que necesitan interactuar profundamente con el mismo estado.

#!/bin/bash

# script_principal_source.sh
echo "Iniciando script principal con source..."
VARIABLE_PADRE="Valor del padre inicial"

echo "Sourcing script_config.sh..."
source ./script_config.sh

echo "Variable del padre después de source: $VARIABLE_PADRE"
echo "Variable definida en el config: $VARIABLE_CONFIG"
MI_FUNCION_GLOBAL

#!/bin/bash

# script_config.sh
echo "  Dentro del script de configuración (sourced)..."
VARIABLE_PADRE="Valor modificado por el config" # ¡CUIDADO! Modifica la del padre
VARIABLE_CONFIG="Configuración cargada"

MI_FUNCION_GLOBAL() {
    echo "  Función global ejecutada."
}

echo "  Cambiando directorio de trabajo a /opt..."
cd /opt # ¡Este cambio afectará al script principal!

Opinión basada en datos reales: Desde mi experiencia en la trinchera del desarrollo y administración de sistemas, source es increíblemente útil para cargar variables de entorno y funciones reutilizables. Sin embargo, su poder es también su mayor riesgo. Un script „sourced” mal diseñado puede sobreescribir variables cruciales o cambiar el directorio de trabajo del script principal de forma inesperada, llevando a errores difíciles de rastrear. Úsalo con respeto y solo cuando necesites una interacción profunda y controlada del entorno. ¡La claridad en el nombre de los archivos y variables es tu mejor aliada aquí!

3. El Comando exec: El Cambio de Identidad 🎭

El comando exec es el menos común de los tres para la orquestación general, pero tiene un caso de uso muy específico y potente. En lugar de ejecutar un script o comando como un subproceso o dentro del proceso actual, exec reemplaza el proceso actual del shell con el nuevo comando o script.

exec mi_otro_script.sh

¿Cómo funciona? 💡 Imagina que tu script actual es un actor en el escenario. Cuando llama a exec, ese actor se va del escenario y otro actor (el script invocado) toma su lugar, asumiendo su identidad. El script original deja de existir y no puede continuar su ejecución. No hay vuelta atrás.

Implicaciones Clave:

• Reemplazo Completo: El script original termina y no puede ejecutar ninguna instrucción después de la llamada a exec.
• Mismo PID: El nuevo script hereda el PID del script que lo invocó.
• Sin Retorno: No puedes capturar un código de salida en el script original porque simplemente deja de existir.

Cuándo usarlo: Principalmente útil cuando el script principal ha terminado su trabajo preparatorio y el paso final es iniciar otro programa o script que asumirá el control total, sin necesidad de que el script principal haga nada más. Por ejemplo, en un script de inicio de sesión o un envoltorio (wrapper) que configura el entorno y luego lanza la aplicación principal.

#!/bin/bash

# script_wrapper.sh
echo "Configurando entorno..."
export APP_CONFIG="/etc/mi_app/config.conf"
echo "Lanzando aplicación principal con exec..."

# A partir de aquí, el script_wrapper.sh deja de existir.
# mi_aplicacion_principal.sh tomará su lugar.
exec ./mi_aplicacion_principal.sh
echo "Esta línea NUNCA se ejecutará."

#!/bin/bash

# mi_aplicacion_principal.sh
echo "  Mi aplicación principal se ha iniciado."
echo "  Configuración utilizada: $APP_CONFIG"
# ... lógica de la aplicación ...
exit 0

El Método Infalible: Orquestación Avanzada y Buenas Prácticas 🛠️

La „infalibilidad” no reside en un solo comando mágico, sino en la comprensión profunda de cómo se comportan estas invocaciones y en la implementación de prácticas robustas para gestionar el flujo, los errores y el entorno. Aquí hay pilares fundamentales:

1. Paso de Argumentos ➡️

Todos los métodos que invocan un nuevo proceso (ejecución directa) permiten pasar argumentos directamente al script secundario. Los argumentos se acceden en el script invocado a través de $1, $2, etc., y todos ellos como $@ o $*.

./mi_script.sh "primer argumento" segundo_argumento

Para scripts „sourced”, los argumentos pasados a la sentencia source se convierten en los argumentos posicionales del script principal después de la llamada a source, lo cual puede ser confuso. Generalmente, para scripts sourced, es mejor usar variables para compartir información.

2. Gestión de Códigos de Retorno ($?) ✅

El código de salida es la espina dorsal de la comunicación entre scripts. Un valor de 0 típicamente indica éxito, mientras que cualquier otro valor (1-255) señala un error. ¡Siempre revisa el código de retorno!

./mi_tarea_critica.sh
if [ $? -ne 0 ]; then
    echo "⚠️ Error: La tarea crítica falló." >&2
    exit 1
fi
echo "✅ Tarea crítica completada con éxito."

Puedes establecer un código de salida específico con exit N en el script invocado.

3. Entorno de Variables: export y Más Allá 💡

Si necesitas que una variable definida en el script principal esté disponible para un script ejecutado en un subproceso, debes exportarla. Esto la convierte en una variable de entorno.

#!/bin/bash
export PATH_DE_LOGS="/var/log/mi_app"
./limpiar_logs.sh

En limpiar_logs.sh, $PATH_DE_LOGS estará disponible. Las variables no exportadas son locales al shell que las define.

4. Redirección de Entrada/Salida (E/S) ⚙️

Puedes controlar cómo el script invocado interactúa con la entrada y salida estándar. Esto es crucial para la captura de logs o el procesamiento en cadena.

• ./script.sh > salida.log: Redirige la salida estándar a un archivo.
• ./script.sh 2> errores.log: Redirige la salida de error estándar a un archivo.
• ./script.sh &> todo.log: Redirige ambas (salida y error) a un archivo.
• ./script.sh | otro_comando: Envía la salida del script como entrada para otro comando.

5. Procesos en Segundo Plano (&) y Espera (wait) ⏳

Si no necesitas que el script principal espere a que el secundario termine, puedes ejecutarlo en segundo plano:

./mi_proceso_largo.sh &
PID_PROCESO=$! # Guarda el PID del último comando en segundo plano

echo "El proceso largo se está ejecutando en segundo plano con PID: $PID_PROCESO"
# El script principal puede seguir haciendo otras cosas
echo "Haciendo algo más mientras el otro script trabaja..."

# Si necesitas esperar a que termine más tarde:
wait $PID_PROCESO
echo "El proceso largo ha finalizado."

Para procesos que deben sobrevivir al cierre del terminal, usa nohup ./mi_proceso_largo.sh &.

6. El Control de Errores Definitivo: set -e y trap 🛑

Para una robustez „infalible”, estos dos comandos son tus mejores amigos:

• set -e: Asegura que el script salga inmediatamente si un comando falla (devuelve un código de salida distinto de cero).
• trap: Permite ejecutar un comando o función cuando ocurre una señal específica, como una salida (EXIT), un error (ERR) o una interrupción (INT).

#!/bin/bash
set -e # Salir en caso de error

function manejar_error {
    echo "❌ Un error inesperado ocurrió en la línea $LINENO." >&2
    exit 1
}

trap manejar_error ERR # Ejecuta manejar_error si cualquier comando falla

echo "Iniciando una secuencia de comandos..."
ls /ruta/inexistente # Esto provocará un error y activará el trap

echo "Esta línea nunca se ejecutará si la anterior falla."

La robustez de un sistema automatizado no se mide por la complejidad de sus componentes, sino por la simplicidad y claridad de cómo estos interactúan entre sí. Un buen script es como un director de orquesta que sabe cuándo cada instrumento debe sonar y cómo armonizar con los demás para una ejecución impecable.

Un Escenario del Mundo Real: Orquestando un Despliegue Automatizado 🌍

Imagina que tienes un pipeline de despliegue. Tu script principal (deploy.sh) necesita:

1. Configurar variables de entorno específicas para el despliegue.
2. Realizar una copia de seguridad de la versión actual (backup_app.sh).
3. Descargar la nueva versión (download_new_version.sh).
4. Desplegar la nueva versión (install_app.sh).
5. Reiniciar el servicio (restart_service.sh).
6. Enviar una notificación de éxito o fallo (notify_status.sh).

Un enfoque robusto sería:

#!/bin/bash
set -e # Detenerse ante el primer error

# --- Configuración Inicial ---
APP_DIR="/opt/mi_aplicacion"
BACKUP_DIR="/var/backups/mi_aplicacion"
VERSION="v2.0"
export NOTIFICATION_EMAIL="[email protected]" # Exportar para el script de notificación

# --- Funciones de Manejo de Errores ---
function deploy_error {
    echo "❌ Error en el despliegue. Consulta los logs." >&2
    ./notify_status.sh "fallo" "$1" # Notificar el fallo con un mensaje
    exit 1
}
trap 'deploy_error "Error inesperado en la línea $LINENO"' ERR # Capturar cualquier error

echo "➡️ Iniciando proceso de despliegue para la versión $VERSION..."

# --- 1. Copia de Seguridad ---
echo "⚙️ Realizando copia de seguridad..."
./backup_app.sh "$APP_DIR" "$BACKUP_DIR"
[ $? -ne 0 ] && deploy_error "Fallo en la copia de seguridad."

# --- 2. Descargar Nueva Versión ---
echo "⬇️ Descargando nueva versión..."
./download_new_version.sh "$VERSION" "$APP_DIR"
[ $? -ne 0 ] && deploy_error "Fallo en la descarga de la nueva versión."

# --- 3. Desplegar la Aplicación ---
echo "📦 Desplegando la aplicación..."
./install_app.sh "$APP_DIR"
[ $? -ne 0 ] && deploy_error "Fallo en la instalación de la aplicación."

# --- 4. Reiniciar Servicio (en segundo plano, si es largo) ---
echo "🔄 Reiniciando servicio (esto puede tomar un momento)..."
./restart_service.sh & # Se ejecuta en segundo plano
WAIT_PID=$!
# Podemos hacer otras cosas aquí si las hubiera
echo "Continuando con otras tareas mientras el servicio reinicia..."
wait $WAIT_PID # Esperar a que el reinicio termine
[ $? -ne 0 ] && deploy_error "Fallo al reiniciar el servicio."

# --- 5. Notificación de Éxito ---
echo "✅ Despliegue completado con éxito."
./notify_status.sh "éxito" "Despliegue de $VERSION finalizado correctamente."

echo "Proceso de despliegue finalizado."
exit 0

Cada script secundario (backup_app.sh, download_new_version.sh, etc.) sería un script ejecutable simple, encargado de su única tarea y devolviendo un código de salida apropiado. La modularidad y la gestión de errores lo hacen robusto.

Conclusión: Tu Orquesta Bash, Bajo Control Absoluto 🎼

Como hemos visto, lanzar un script desde otro script en Bash es mucho más que simplemente escribir una ruta. Es un arte que requiere comprensión de los entornos de ejecución, la gestión de procesos y una estrategia sólida para el manejo de errores. El „método infalible” no es una única línea de código, sino la aplicación consciente de las herramientas adecuadas para cada situación. Se trata de entender las implicaciones de usar ./script.sh, source o exec, y de blindar tu orquestación con la revisión de códigos de retorno, la exportación de variables y los mecanismos de set -e y trap.

Te animo a experimentar con cada uno de estos métodos, a romper tus propios scripts para entender cómo se comportan y, sobre todo, a adoptar una mentalidad de robustez. Diseña tus scripts como si fueran a fallar, y entonces estarán preparados para triunfar. Con estas técnicas en tu arsenal, tendrás el control total sobre la coreografía de tus automatizaciones, convirtiendo tareas complejas en procesos fluidos y confiables. ¡Ahora sal y haz que tus scripts canten en perfecta armonía! ✨