Cerraste el Módulo 2 con criterio para decidir quién accede a qué. Empiezas el Módulo 3 con algo más íntimo: el sitio donde trabajas. Cada vez que abres una sesión en srv-tramontana, Bash construye a tu alrededor un entorno —un conjunto de variables, atajos, rutas de búsqueda y memoria de lo que ya hiciste— que determina cómo se comportan todos los comandos que ejecutes después. Hasta ahora lo has usado tal como venía de fábrica. A partir de aquí lo entiendes y lo moldeas.

No es un capricho estético. El 90 % de los «pero si a mí me funcionaba» de un administrador de sistemas —el script que va desde tu terminal y falla en cron, el sort que ordena distinto en tu portátil y en el servidor, el comando que existe para operador pero no para root— son problemas de entorno. Entender qué se hereda, qué no y desde qué fichero se carga cada cosa es lo que separa depurar en cinco minutos de perder una tarde.

1. Qué es el entorno de un proceso
2. Variables de shell y variables de entorno
3. La herencia hacia los procesos hijos
4. PATH: cómo encuentra Bash un ejecutable
5. Las otras variables que importan
6. Expansión de variables y comillas, con precisión
7. Sustitución de comandos
8. Alias
9. Shells de login, interactivos y no interactivos
10. Personalizar el prompt PS1
11. Historial persistente y su riesgo de seguridad
12. El ~/.bashrc recomendado para operador

Cuando el kernel arranca un proceso, le entrega tres cosas: los argumentos de la línea de comandos, los descriptores de archivo abiertos (que verás en 03-04) y un vector de cadenas CLAVE=valor llamado entorno. No es magia de Bash: es una estructura del sistema operativo, disponible para cualquier programa escrito en cualquier lenguaje.

Como en Linux todo es un archivo, puedes verlo directamente:

$$ es el PID del shell actual. El fichero environ guarda las variables separadas por bytes nulos, por eso hace falta tr para leerlas. Lo importante: ese contenido se fijó cuando el proceso arrancó. Es una fotografía, no un enlace vivo.

Bash maneja dos conjuntos que se parecen y no son lo mismo.

La asignación tiene una regla que provoca errores el primer día: no puede haber espacios alrededor del =.

Con espacios, Bash interpreta RELEASE como un comando y = y 3.2.1 como sus argumentos. Si el valor lleva espacios, hay que entrecomillarlo: MENSAJE="despliegue ok".

Para promover una variable ya existente a variable de entorno basta export RELEASE. Para eliminar cualquiera de las dos, unset RELEASE.

Ver una en concreto:

printenv VARIABLE imprime su valor y devuelve 1 si la variable no está en el entorno, aunque exista como variable de shell. Es la forma más rápida de comprobar si te falta un export.

Este es el concepto que hay que dejar cerrado, porque explica una familia entera de errores. La herencia es unidireccional y en el momento del arranque: el hijo recibe una copia del entorno del padre, y nada de lo que el hijo haga vuelve al padre.

El hijo cambió su copia y murió con ella. Por eso un script no puede cambiar el directorio de trabajo de tu terminal, ni definirte una variable, salvo que lo ejecutes con source (o su sinónimo .), que no crea un proceso hijo: lee el fichero en el shell actual.

Los paréntesis crean un subshell, que es un hijo más y se comporta igual: ( cd /opt/tramontana/app && pwd ) imprime /opt/tramontana/app y te deja donde estabas. Ese patrón es útil de verdad: te desplazas, haces algo y vuelves solo, sin arriesgarte a olvidar un cd -.

En el Módulo 2 quedó como noción. Ahora en detalle. PATH es una lista de directorios separados por :, y Bash la recorre de izquierda a derecha, parándose en la primera coincidencia.

type -a muestra todas las coincidencias en orden; si hubiera dos versiones instaladas, verías cuál gana. Bash además cachea las rutas resueltas: si instalas un binario que enmascara a otro y sigue ejecutándose el antiguo, hash -r limpia esa caché.

Para añadir /home/operador/scripts, la forma correcta es anteponer o añadir sin destruir lo que ya había:

Fíjate en dos detalles. Primero, se reutiliza $PATH dentro del nuevo valor; escribir PATH=/home/operador/scripts a secas deja el sistema sin ls ni sudo hasta que cierres la sesión. Segundo, va entrecomillado.

Poniéndolo delante, tus scripts tienen prioridad sobre los del sistema, lo que permite sobrescribir un comando a propósito; poniéndolo detrás (PATH="$PATH:$HOME/scripts") el sistema gana siempre, que es más conservador. En Tramontana usamos el segundo orden para las cuentas administrativas.

Incluir el directorio actual parece cómodo y es un agujero de seguridad clásico. Imagina que . está el primero y que Luis, depurando, deja en /srv/tramontana/backups/temporales/ un archivo llamado ls con contenido malicioso. Entras ahí a mirar, escribes ls, y en lugar del comando del sistema ejecutas el archivo de ese directorio con tus privilegios. Con sudo de por medio, es una escalada de privilegios completa.

La regla es absoluta: . no va en el PATH, ni al principio ni al final. Para ejecutar algo del directorio actual se escribe ./programa, explícitamente. Esos dos caracteres son la diferencia entre una decisión consciente y un accidente.

La locale merece un párrafo propio porque produce diferencias silenciosas entre máquinas:

Con es_ES.UTF-8, sort ignora mayúsculas y guiones y ordena «como un diccionario». Con LC_ALL=C ordena por valor de byte, y todas las mayúsculas van antes que las minúsculas. Cuando el orden tiene que ser reproducible —comparar dos listados, generar una suma de verificación— fija LC_ALL=C. Fíjate también en que la asignación va delante del comando, sin export: eso define la variable solo para esa ejecución, sin tocar tu sesión. Es el modo más limpio de probar cosas.

LC_ALL pisa a todas las demás LC_* y a LANG; por eso es la que se usa para forzar. El mismo efecto aparece en las fechas: date te dará «lun ago 18» o «Mon Aug 18» según la locale, y si un script recorta esa salida por posición, se rompe al cambiar de máquina.

El Módulo 2 dio las comillas por encima. Aquí va la regla exacta, que es de las tres o cuatro cosas más rentables de todo el curso.

La diferencia entre las dos primeras filas rompe scripts todos los días:

Sin comillas, Bash parte el valor por el espacio y ls recibe dos argumentos. La regla de oro: entrecomilla siempre "$VAR", salvo que quieras deliberadamente que se parta en palabras.

Las llaves ${VAR} delimitan el nombre cuando lo que sigue podría confundirse con parte de él. Con V=3.2.1, echo "release-$V_final" imprime release- —Bash busca una variable V_final, que no existe— mientras que echo "release-${V}_final" imprime release-3.2.1_final.

Dos expansiones con valor por defecto que usarás constantemente:

• ${VAR:-valor} usa valor si VAR está vacía o no definida, sin asignarla. Ideal para valores por defecto.
• ${VAR:?mensaje} aborta con ese mensaje si falta. Es la forma corta de exigir un parámetro obligatorio.

Existe también ${VAR:=valor}, que además asigna, y ${VAR:+valor}, que usa valor solo si la variable sí está definida.

$(comando) ejecuta el comando y sustituye la expresión por su salida, quitando los saltos de línea finales.

Ya lo venías usando en la convención de copias de seguridad cp app.conf app.conf.bak-$(date +%F). Ahora sabes exactamente qué ocurre ahí.

Existe la forma antigua con acentos graves, `comando`. Usa siempre $(...): se puede anidar sin escapar nada y no se confunde visualmente con las comillas simples. Y entrecomilla el resultado, "$(...)", por la misma razón del apartado anterior.

Un alias es una abreviatura que Bash sustituye al principio de un comando, antes de ejecutarlo.

Se eliminan con unalias ll. Para ejecutar el comando original saltándote el alias, antepón una barra invertida:

También sirven command rm y la ruta absoluta /bin/rm. Esto importa porque los alias son locales a tu sesión interactiva: no existen en un script, ni en cron, ni cuando otro usuario ejecuta lo mismo. Un alias rm='rm -i' te da una falsa sensación de red de seguridad que desaparece justo en el contexto donde más daño harías.

Los alias son para tu comodidad, no para automatizar. Si necesitas que algo se comporte igual siempre y en todas partes, eso es un script, y los scripts son el Módulo 4. En el apartado 12 verás el juego completo que usamos en Tramontana.

Aquí está el lío que hay que deshacer de una vez. Bash lee ficheros de arranque distintos según cómo se ha lanzado.

De ese diagrama salen tres consecuencias que resuelven casi todas las dudas:

1. Las variables de entorno van en ~/.profile; los alias, funciones y PS1 van en ~/.bashrc. Lo primero se hereda por todos los procesos de la sesión; lo segundo solo tiene sentido cuando hay alguien tecleando.
2. En Ubuntu, ~/.profile termina con un bloque que hace source ~/.bashrc. Por eso al conectarte por SSH ves tus alias: llegan por esa cadena, no porque el shell de login lea .bashrc por sí mismo. Si creas un ~/.bash_profile, ~/.profile deja de leerse y esa cadena se rompe.
3. Cron no lee nada de esto, y esa es la causa raíz del fallo clásico que estudiarás en 03-07.

Para saber en qué tipo de shell estás: shopt -q login_shell && echo login te dice si es de login, y echo "$-" muestra las opciones activas, donde la i indica interactivo. Y ~/.bash_logout se ejecuta al cerrar un shell de login: sirve, por ejemplo, para limpiar la pantalla de un TTY físico con clear.

PS1 es la cadena que Bash imprime antes de cada comando. Admite secuencias de escape propias:

El color se añade con secuencias ANSI, y hay un detalle imprescindible: todo lo que no ocupa espacio en pantalla debe ir entre \\[ y \\]. Si te lo saltas, Bash calcula mal la anchura de la línea y el historial se pinta encima del prompt al recuperar comandos largos.

En producción usamos otro color a propósito:

Texto blanco sobre fondo rojo (41). En Tramontana, el prompt de srv-tramontana va en rojo y el del portátil en verde, por una razón muy poco estética: casi todos los borrados catastróficos empiezan por ejecutar en la ventana equivocada un comando pensado para la otra. Un aviso visual permanente e imposible de ignorar es más eficaz que cualquier norma escrita. La misma lógica se aplica cuando trabajas como root, donde el \$ pasa a # por sí solo.

Bash guarda los comandos en memoria durante la sesión y los vuelca a ~/.bash_history al salir. Ese comportamiento por defecto tiene dos problemas: si abres varias terminales, la última en cerrarse sobrescribe el historial de las demás, y si la sesión muere de golpe, se pierde todo.

ignoreboth incluye ignorespace, y eso habilita un truco práctico: si escribes un comando precedido de un espacio, no se guarda. Con HISTTIMEFORMAT puesto, history 3 te muestra las tres últimas entradas con su marca de tiempo, lo que convierte el historial en un registro de qué hiciste y cuándo.

~/.bash_history es un fichero de texto plano. Todo lo que escribas en la línea de comandos acaba ahí, incluidas las credenciales:

Esa contraseña queda escrita en tu historial, y además es visible en la tabla de procesos para cualquier usuario del sistema mientras el comando corre (lo verás con ps aux en 03-06). Dos problemas, no uno.

Qué hacer en su lugar:

• Deja que la herramienta la pida de forma interactiva (mysql -u tramontana -p, sin pegarla).
• Guárdala en un fichero de credenciales con permisos 600 y pásale la ruta.
• Si ya la has escrito: bórrala del historial en memoria y del fichero.

Y comprueba los permisos, que deben ser 600. La gestión seria de secretos es la lección 06-05; aquí quédate con la higiene mínima.

Reuniendo todo, este es el bloque que añadimos al final de ~/.bashrc en las cuentas administrativas de Tramontana. Aplica la convención del curso: copia de seguridad antes de editar y diff -u después.

Se activa sin cerrar la sesión con source ~/.bashrc, y se verifica el cambio con diff -u ~/.bashrc.bak-2026-08-18 ~/.bashrc. Fíjate en que umask 027 va aquí y no en ~/.profile porque nos interesa para el trabajo interactivo; para los servicios se fija en otro sitio, y eso es materia de 05-05.

• Espacios alrededor del =. VAR = valor no es una asignación. Es el error número uno.
• Editar ~/.bashrc y esperar que se aplique solo. Hay que hacer source ~/.bashrc o abrir una sesión nueva.
• Romper el PATH. Antes de tocarlo, guarda una copia: PATH_ORIG="$PATH". Si te quedas sin comandos, export PATH="$PATH_ORIG" te salva sin reconectar.
• Poner variables de entorno en ~/.bashrc. Funciona en interactivo y desaparece en contextos no interactivos. Su sitio es ~/.profile.
• Crear ~/.bash_profile sin saber que anula ~/.profile. Si lo creas, incluye dentro [ -f ~/.profile ] && . ~/.profile.
• Confiar en alias rm='rm -i'. No existe en scripts ni en cron. La red de seguridad de verdad es mirar con ls antes del rm.
• Olvidar \\[ \\] en los colores del PS1. El síntoma es un prompt que se corrompe al navegar por el historial.
• Consejo: env -i comando arranca un programa sin ninguna variable. Es la mejor forma de reproducir lo que ve cron, y volverás a ello en 03-07. Y como set sin argumentos lista variables y funciones, filtra siempre: set | grep '^HIST'.

Ejercicio 1. Demuestra en tu VM la diferencia entre variable de shell y variable de entorno. Define DESPLIEGUE=3.3.0 sin exportar, comprueba que un bash -c hijo no la ve, expórtala, comprueba que ahora sí, y explica por qué printenv daba error antes.

Ejercicio 2. Añade /home/operador/scripts al PATH de forma que no tenga prioridad sobre los comandos del sistema y que el cambio sobreviva a reconectar por SSH. Verifica que funciona sin cerrar la sesión y explica en qué fichero lo has puesto y por qué.

Ejercicio 3. Genera una lista ordenada y reproducible de las casas de /home/operador/datos/casas.txt que sea idéntica en tu portátil y en el servidor, aunque tengan locales distintas. Guarda el resultado en /home/operador/datos/casas-ordenadas.txt y justifica la decisión.

Solución 1.

La variable existía desde el principio en el shell actual —por eso echo la mostraba—, pero no estaba en el vector de entorno que se copia a los hijos. printenv consulta exactamente ese vector, así que no la encontró y devolvió 1. export no crea la variable: la marca para exportación, y a partir de ahí todos los hijos nuevos la reciben. Los que ya estuvieran corriendo, no: la herencia ocurre en el momento del fork.

Solución 2. Debe ir en ~/.profile, porque es una variable de entorno y porque ~/.profile se lee en los shells de login, que es lo que abre SSH. Al final, y no al principio, para que el sistema tenga prioridad.

source aplica el cambio a la sesión actual sin reconectar. Si en lugar de eso hubiéramos escrito PATH="$HOME/scripts:$PATH", un script nuestro llamado df o tar enmascararía al del sistema, y ese tipo de sorpresa es difícil de diagnosticar. Ponerlo al final es la opción conservadora. Nótese también que las comillas simples del printf impiden que $PATH y $HOME se expandan al escribir el fichero: queremos que la expansión ocurra en cada login, no ahora.

Solución 3.

La justificación es la clave del ejercicio: sin LC_ALL=C, el resultado depende de la locale de cada máquina. Con es_ES.UTF-8 el guion se ignora en la comparación y mas-figueres podría quedar en otra posición respecto a un hipotético masfigueres; con C se compara byte a byte y el resultado es idéntico en cualquier sistema. Cuando la salida va a compararse, versionarse o alimentar otro proceso, la reproducibilidad pesa más que la corrección ortográfica del orden. Y se pone delante del comando, sin export, para no alterar el resto de la sesión.

Has pasado de habitar el entorno del shell a diseñarlo.

• El entorno es un vector CLAVE=valor que el kernel entrega a cada proceso; lo lees en /proc/<pid>/environ.
• Distingues variable de shell de variable de entorno: export marca la diferencia, y la herencia es unidireccional y en el momento del arranque, por eso un script no puede cambiarte el cd salvo con source.
• Entiendes cómo Bash busca un ejecutable recorriendo el PATH de izquierda a derecha, cómo ampliarlo sin destruirlo, y por qué . nunca va en el PATH.
• Conoces el efecto real de la locale sobre sort y las fechas, y usas LC_ALL=C cuando necesitas resultados reproducibles.
• Manejas con precisión "$VAR" frente a $VAR y '$VAR', las llaves ${VAR}, los valores por defecto ${VAR:-...} y ${VAR:?...}, y la sustitución de comandos $(...).
• Tienes desenredado el lío de los ficheros de arranque: entorno en ~/.profile, alias y PS1 en ~/.bashrc, y nada de eso en un shell no interactivo.
• Has puesto el prompt de producción en rojo por una razón operativa y configurado un historial persistente con histappend, sabiendo que las contraseñas escritas en la línea acaban en un fichero de texto plano.

La siguiente lección da el paso natural. Ya sabes describir un archivo con su ruta; ahora aprenderás a describir conjuntos de archivos y patrones de texto. En Comodines y Expresiones Regulares verás la distinción que casi nadie explica bien —que el globbing lo hace el shell antes de ejecutar el comando, mientras que las expresiones regulares las interpreta el programa que las recibe—, y esa distinción, que ahora entenderás porque ya sabes cómo Bash procesa una línea antes de lanzarla, es la que evita que grep *.log haga algo completamente distinto de lo que esperabas.