Diseño de funciones con ámbito local y códigos de retorno

En Bash, las variables son globales de forma predeterminada. Una variable definida dentro de una función se filtra al ámbito de quien la llama, a menos que la declare explícitamente como local. Esta es una fuente habitual de errores sutiles en los scripts de shell.

• Las funciones sin local pueden sobrescribir silenciosamente las variables de quien las llama.
• Las variables local se destruyen cuando la función retorna.
• Unos límites de ámbito claros hacen que las funciones sean reutilizables y comprobables de forma aislada.

En esta lección aprenderá a escribir funciones autónomas: utilizan variables local, comunican los resultados mediante códigos de salida y printf, y nunca dependen de un estado global implícito.

Aquí tiene un ejemplo concreto de una fuga de una variable global. La función set_name establece una variable llamada result, que sobrescribe silenciosamente la propia variable result de quien la llama.

Ejecute este script y observe la salida inesperada: la variable result de quien llama desaparece después de la llamada a la función.

El elemento integrado local restringe el ámbito de una variable a la función contenedora y a cualquier función que esta llame. Fuera de la función, la variable no está definida o conserva su valor anterior.

• local varname — declara sin asignar.
• local varname="value" — declara y asigna en un solo paso.
• local -i count=0 — declara una variable local de tipo entero.
• local -r PI=3.14159 — declara una constante local de solo lectura.

Buena práctica: declare como local todas las variables dentro de una función, a menos que necesite intencionadamente que sean globales.

Las funciones de Bash no pueden devolver cadenas con return; return solo establece un estado de salida entero (0–255). Por convención:

• return 0 — éxito
• return 1 (o cualquier valor distinto de cero) — error

Quien llama lee el estado de salida mediante $? inmediatamente después de la llamada, o usa la función directamente en una condición if. Los códigos de salida son la forma idiomática de indicar éxito o error desde una función.

Cuando una función necesita devolver un resultado de tipo cadena, el patrón estándar consiste en imprimir en stdout y capturar el resultado con una sustitución de comandos $(). Se prefiere usar printf en lugar de echo porque:

• printf no añade un salto de línea final de forma predeterminada (a menos que incluya \n).
• El comportamiento de printf es coherente y está definido por POSIX; echo varía según el shell.
• La sustitución de comandos elimina los saltos de línea finales, por lo que printf '%s' "$value" es preciso.

Una función bien diseñada puede tanto imprimir un resultado (si tiene éxito) como indicar un error (mediante el código de salida) al mismo tiempo. Quien llama decide qué hacer basándose en el código de salida antes de confiar en el resultado.

El patrón siguiente se usa ampliamente en bibliotecas reales de Bash:

• Si tiene éxito: imprime el resultado con printf y ejecuta return 0.
• Si falla: escribe un diagnóstico en stderr (no en stdout) y ejecuta return 1.
• Escribir los errores en stderr mantiene stdout limpio para las tuberías.

La recursión demuestra con claridad por qué local es esencial. Cada llamada recursiva obtiene su propia copia independiente de cada variable local en la pila de llamadas. Sin local, cada llamada sobrescribiría la misma variable global y produciría resultados incorrectos.

La función factorial siguiente es segura porque n y sub son locales para cada marco de la pila.

La sustitución de comandos $() se ejecuta en un subshell. Las asignaciones de variables que se hagan dentro de él no son visibles para el shell padre. Cuando necesite que una función escriba en una variable proporcionada por quien la llama sin usar un subshell, utilice un nameref (local -n), disponible en Bash 4.3 y versiones posteriores.

• local -n ref="$1" convierte ref en un alias de la variable cuyo nombre está almacenado en $1.
• Asignar un valor a ref dentro de la función modifica directamente la variable de quien la llama.
• Esto evita un subshell y mantiene locales los detalles de implementación.

Los proyectos de Bash del mundo real separan las funciones reutilizables en archivos de biblioteca que los scripts cargan mediante source (o el operador punto .). Reglas para diseñar buenas bibliotecas:

• Toda variable dentro de una función de biblioteca debe ser local.
• Las funciones de biblioteca nunca ejecutan exit: ejecutan return, para que quien las llama siga ejecutándose.
• Use un prefijo de espacio de nombres coherente (por ejemplo, str_, log_) para evitar colisiones de nombres.
• Evite cargar el mismo archivo dos veces mediante una variable centinela.

A continuación se muestra una biblioteca mínima de utilidades para cadenas que sigue estas convenciones.

Las funciones que reciben argumentos deben validarlos al principio y devolver un código de salida específico si la entrada no es válida. Este patrón se denomina cláusula de guarda: fallar rápido y de forma clara.

• Compruebe el número de argumentos con $#.
• Valide los tipos o formatos antes de realizar cualquier operación.
• Imprima los mensajes de diagnóstico únicamente en stderr, nunca en stdout.
• Use códigos de retorno distintos de cero (por ejemplo, 1 = argumentos incorrectos, 2 = archivo no encontrado) para que quien llama pueda reaccionar de forma diferente a cada tipo de error.

Aquí tiene un script completo y autocontenido que demuestra cómo funcionan conjuntamente todos los conceptos de esta lección:

• Variables local en todas las funciones.
• Códigos de salida para indicar éxito o error.
• printf para comunicar resultados de tipo cadena.
• Errores escritos en stderr y resultados en stdout.
• Cláusulas de guarda para validar argumentos.

Estudie el flujo: parse_version extrae los datos, version_ge los compara y main utiliza ambas funciones correctamente.

Considere la siguiente función de Bash. ¿Cuál es la forma correcta de capturar su resultado de tipo cadena en quien la llama y qué afirmación sobre la variable tmp es verdadera?

transform() {
    local tmp="${1,,}"   # lowercase
    printf '%s' "$tmp"
    return 0
}

En esta lección ha aprendido a escribir funciones de Bash limpias, componibles y seguras:

• Use siempre local para las variables dentro de las funciones y evitar contaminar el ámbito de quien las llama.
• Use códigos de salida (return 0/1/N) para indicar éxito o error; se integran de forma natural con if, && y ||.
• Use printf en stdout para comunicar resultados de tipo cadena y captúrelos con $() en quien llama.
• Escriba los errores en stderr (>&2) para que stdout se mantenga limpio para el flujo de datos y las tuberías.
• Use local -n (nameref) cuando necesite escribir en una variable proporcionada por quien llama sin el coste de un subshell.
• Las cláusulas de guarda (validar los argumentos al principio y devolver el control inmediatamente si la entrada no es válida) hacen que las funciones sean robustas y fáciles de entender.
• Los archivos de biblioteca deben cargarse mediante source, usar prefijos de espacio de nombres, no ejecutar nunca exit y evitar que se carguen dos veces.

Dominar estos patrones marca la diferencia entre scripts frágiles y puntuales y bases de código Bash profesionales y fáciles de mantener.