En la lección anterior conociste a Veloz Envíos y el toolkit veloz-ops que construiremos durante el curso. Antes de escribir la primera línea de ese toolkit necesitas un entorno de trabajo en condiciones: Bash instalado y en una versión moderna, una terminal cómoda, tus ficheros de configuración bajo control y el esqueleto de directorios del proyecto ya creado. Esta lección es la que más se salta la gente y la que más problemas evita: un entorno mal montado produce errores incomprensibles semanas después ("en mi máquina funciona, en el servidor no"). Vamos a dejarlo bien desde el principio.

1. Comprobar si ya tienes Bash y en qué versión
2. Bash en Linux
3. Bash en macOS: el problema de la versión 3.2
4. Bash en Windows: WSL2 y Git Bash
5. Abrir una terminal y elegir emulador
6. Los ficheros de configuración de Bash y cuándo se lee cada uno
7. Personalización básica: PS1, alias y PATH
8. Crear el esqueleto del proyecto ~/veloz-ops
9. Recargar la configuración con source
10. Elegir editor: nano, vim, VS Code

Lo primero, siempre, es averiguar de qué partimos. Hay dos formas complementarias de preguntar por la versión de Bash.

Este comando ejecuta el programa bash que se encuentre en tu PATH y le pide que se identifique. Es la versión que se usaría al lanzar un script nuevo.

Aquí no ejecutas ningún programa: consultas una variable interna del shell que tienes abierto ahora mismo. La diferencia importa: si tu terminal arranca Zsh, bash --version te dirá qué Bash hay instalado, pero $BASH_VERSION estará vacío porque no estás dentro de Bash.

Para este curso trabajaremos sobre Bash 5.x, que es lo que trae srv-veloz-01 (Ubuntu 24.04 LTS). Los dos puntos donde la versión te morderá de verdad son:

• Arrays asociativos (declare -A, los "diccionarios" de Bash). Los usaremos en el Módulo 4 para contar envíos por ciudad. No existen antes de Bash 4.
• ${var@Q}, que devuelve el valor de una variable citado de forma segura para reutilizarlo. Es muy útil en depuración y logging, y requiere Bash 4.4 o superior.

Si tu versión es inferior a 4.4, sigue leyendo: la sección de macOS explica cómo actualizar.

Es el caso más sencillo: prácticamente todas las distribuciones traen Bash instalado y como shell por defecto del usuario. Si por algún motivo faltara:

Detalle importante para el caso de Alpine: las imágenes Docker basadas en Alpine no traen Bash, solo ash de BusyBox. Si un Dockerfile de Veloz Envíos usa RUN bash script.sh sobre Alpine sin instalarlo, fallará con bash: not found. Es un clásico.

Para saber qué shell tienes asignado como shell de login:

Cuidado con una confusión frecuente: $SHELL no indica el shell que estás ejecutando ahora, sino el que tienes configurado en /etc/passwd como shell de inicio de sesión. Si abres Bash desde dentro de Zsh, $SHELL seguirá diciendo /bin/zsh. La forma fiable de saber dónde estás la veremos en 01-04.

Para cambiar tu shell de login de forma permanente:

El cambio se aplica en la siguiente sesión, no en la actual.

macOS incluye Bash, pero congelado en la versión 3.2 de 2007. El motivo no es técnico sino de licencias: a partir de Bash 4, el proyecto GNU pasó a la licencia GPLv3, que Apple no incorpora en su sistema. Además, desde Catalina el shell por defecto de las cuentas nuevas es Zsh.

Comprueba tu situación:

Si vas a seguir este curso desde macOS, instala un Bash moderno con Homebrew:

Homebrew no reemplaza el /bin/bash del sistema (macOS lo protege): instala uno nuevo en /opt/homebrew/bin/bash (Apple Silicon) o /usr/local/bin/bash (Intel). Para que sea el que se use:

En tus scripts, usa siempre #!/usr/bin/env bash en lugar de #!/bin/bash: la primera forma busca Bash en el PATH y encontrará el moderno, mientras que la segunda apunta rígidamente al 3.2 de Apple.

Windows no trae Bash, pero hay dos caminos con propósitos muy distintos.

WSL2 (Windows Subsystem for Linux 2) ejecuta un kernel Linux real dentro de Windows. No es una emulación: es una máquina virtual ligera perfectamente integrada. Es lo más parecido a trabajar en srv-veloz-01 que puedes tener en un portátil Windows.

Desde PowerShell como administrador:

Tras reiniciar y crear tu usuario Linux, ya tienes un Ubuntu completo con Bash 5.2. Comandos útiles desde PowerShell:

Dentro de WSL, tus discos de Windows aparecen bajo /mnt/c, /mnt/d, etc.

Un consejo de rendimiento que ahorra muchos disgustos: guarda tus proyectos dentro del sistema de ficheros de Linux (/home/tu_usuario/...), no en /mnt/c/.... El acceso entre sistemas de ficheros es lento y los permisos de Linux no se representan correctamente en NTFS.

Git for Windows incluye Git Bash: un Bash compilado para Windows con un conjunto mínimo de utilidades Unix (ls, grep, sed, ssh). Es cómodo para usar Git y ejecutar scripts sencillos, pero no es Linux: no hay systemd, no hay gestor de paquetes, faltan muchas herramientas y algunos comportamientos difieren.

A partir del Módulo 7 (cron, systemd) Git Bash directamente no servirá. Si trabajas en Windows, instala WSL2.

La forma de abrir una terminal depende del sistema:

Emuladores habituales y por qué elegir uno u otro:

• GNOME Terminal / Konsole: los que trae tu escritorio. Sobradamente suficientes para empezar.
• Windows Terminal: obligatorio en Windows; gestiona pestañas de PowerShell, CMD y WSL en la misma ventana, con buen soporte de colores y fuentes.
• iTerm2 (macOS): división de paneles, búsqueda en el histórico, perfiles. El estándar entre profesionales de Mac.
• Alacritty / WezTerm / Kitty: emuladores acelerados por GPU, muy rápidos con salidas de log enormes.
• La terminal integrada de VS Code: cómoda porque tienes editor y shell en la misma ventana.

Recuerda lo visto en 01-01: el emulador no es el shell. Cambiar de Alacritty a Kitty no cambia una coma de tu Bash.

Este es el punto donde más confusión existe, y merece que lo entiendas de verdad. Bash lee ficheros distintos según cómo se haya arrancado, y hay dos ejes independientes.

• Shell de login: es el primero que se arranca cuando te autenticas. Ocurre al entrar por SSH a srv-veloz-01, al iniciar sesión en una consola de texto, o al ejecutar bash --login.
• Shell interactivo: tiene un prompt y espera que teclees. Abrir una pestaña de terminal en el escritorio arranca un shell interactivo que no es de login.
• Shell no interactivo: ejecuta un script y termina. No hay prompt ni persona delante. Es el caso de un script lanzado por cron.

De la tabla se deduce el problema clásico: si pones tus alias en ~/.bash_profile, no aparecerán al abrir una pestaña de terminal (que es no-login), y si los pones solo en ~/.bashrc, no aparecerán al entrar por SSH (que es login). La solución universalmente adoptada es que ~/.bash_profile cargue ~/.bashrc:

Desglose línea a línea:

• if [ -f ~/.bashrc ]; then comprueba si existe un fichero regular llamado ~/.bashrc. La opción -f significa "es un fichero normal". Las condicionales se estudian a fondo en 03-04.
• El punto solitario . es sinónimo de source: ejecuta el contenido de ese fichero en el shell actual, como si lo hubieras tecleado.
• fi cierra el if (es if escrito al revés, una convención de Bash).

En Ubuntu, ~/.profile ya trae esta lógica de fábrica. Si creas un ~/.bash_profile propio, ten en cuenta que ~/.profile dejará de leerse, porque Bash solo lee el primero que encuentre de los tres.

La regla de oro, y lo que debes recordar:

PS1 es la variable que define el aspecto del prompt. Bash admite unas secuencias de escape propias:

Un prompt algo más informativo con color, pensado para trabajar en servidores:

Aquí \e[32m activa el verde, \e[34m el azul y \e[0m restablece el color por defecto. Los delimitadores \\[ y \\] son imprescindibles: le indican a Bash que lo que hay dentro no ocupa espacio en pantalla. Si los omites, el shell calculará mal la longitud de la línea y verás el texto pisándose al usar el historial.

Un consejo profesional muy útil: usa colores distintos en tu portátil y en el servidor de producción. Un prompt rojo en srv-veloz-01 es un recordatorio visual constante de dónde estás tecleando, y previene el clásico rm ejecutado en la máquina equivocada.

Un alias es un atajo: una palabra que Bash sustituye por otra cosa antes de ejecutar.

Ahora, escribir ll equivale a escribir ls -lh. Aspectos que debes conocer:

• No dejes espacios alrededor del =: alias ll = 'ls -lh' da error.
• Los alias solo funcionan en shells interactivos. Un script no los ve; por eso en scripts se usan funciones (Módulo 4), no alias.
• alias sin argumentos lista todos los definidos.
• Para saltarte temporalmente un alias, antepone una barra invertida: \ls ejecuta el ls real.

PATH es una lista de directorios, separados por dos puntos, donde Bash busca los programas cuando escribes un nombre de comando.

Cuando escribes date, Bash recorre esos directorios de izquierda a derecha y ejecuta la primera coincidencia. El mecanismo completo de búsqueda lo desmenuzaremos en la lección 01-04.

Para añadir un directorio propio:

Tres detalles que importan:

• export hace que la variable se herede por los programas que lances desde este shell. Sin export solo existiría en el shell actual.
• Poner $HOME/veloz-ops/bin delante significa que tus scripts tienen prioridad. Ponerlo detrás ($PATH:$HOME/veloz-ops/bin) es más conservador, porque evita que un script tuyo llamado ls sombree al del sistema.
• Nunca incluyas . (el directorio actual) en el PATH. Es un riesgo de seguridad clásico: bastaría con que alguien dejara un fichero llamado ls en un directorio compartido para que lo ejecutaras sin querer. Lo trataremos en 08-03.

Llega el momento de crear la estructura que nos acompañará todo el curso. Cada directorio tiene un propósito claro, imitando la convención de cualquier paquete Unix:

Créalo con un solo comando:

Analicemos esta línea, porque tiene dos ideas nuevas:

• mkdir crea directorios. La opción -p significa "crea también los directorios padre que hagan falta y no te quejes si ya existen". Sin -p, el comando fallaría si ~/veloz-ops no existiera todavía.
• {bin,lib,etc,logs} es una expansión de llaves: Bash la convierte en cuatro rutas antes de ejecutar nada. Es decir, mkdir recibe realmente cuatro argumentos. Esta expansión se estudia en 02-05.

Comprueba el resultado:

Ahora añade bin/ al PATH de forma permanente. Abre ~/.bashrc con tu editor y añade al final:

Observa que se usa $HOME y no ~. Dentro de comillas dobles, la virgulilla no se expande, así que "~/veloz-ops/bin" crearía una ruta literal inválida. $HOME sí funciona siempre. Es un error muy habitual y difícil de detectar.

Has editado ~/.bashrc, pero tu shell abierto no se entera solo: leyó ese fichero al arrancar y no vuelve a mirarlo. Tienes dos opciones: cerrar y abrir la terminal, o recargarlo.

O de forma equivalente y más portable:

source ejecuta el contenido del fichero en el shell actual, de modo que las variables y alias que define quedan disponibles aquí y ahora. Esto es distinto de ejecutar el fichero como un script: en ese caso Bash arrancaría un proceso hijo, definiría las variables allí y las perdería al terminar. Esa diferencia —fundamental y responsable de innumerables horas perdidas— la entenderás del todo en la lección 01-04, al hablar de subshells.

Verifica que ha funcionado:

Este comando parte el PATH por los dos puntos y muestra las tres primeras entradas; tr y las tuberías se explican en el Módulo 2, aquí solo lo usamos para leer cómodamente.

Un aviso: si ejecutas source ~/.bashrc varias veces, la línea export PATH="$HOME/veloz-ops/bin:$PATH" añadirá el directorio repetidamente. No es grave, pero ensucia. Una versión defensiva:

La sentencia case se ve en 04-05; guárdala como receta por ahora.

Vas a escribir muchos ficheros de texto. Elige una herramienta y apréndela mínimamente.

Los atajos aparecen en la parte inferior; ^ significa Ctrl. Los tres imprescindibles: Ctrl+O guarda, Ctrl+X sale, Ctrl+W busca.

Vim es modal, y ahí está su dificultad inicial. La supervivencia mínima:

• Arrancas en modo normal (los caracteres son órdenes, no texto).
• i entra en modo inserción para escribir.
• Esc vuelve a modo normal.
• :w guarda, :q sale, :wq guarda y sale, :q! sale descartando cambios.

Aunque no lo adoptes, aprende ese mínimo: en un servidor recién instalado puede ser el único editor disponible.

Si trabajas en Windows con WSL2, instala la extensión WSL de Microsoft. Entonces, desde tu terminal de Ubuntu:

VS Code se abrirá en Windows pero trabajando dentro del sistema de ficheros de Linux, con su terminal integrada apuntando a Bash. Es la mejor combinación de comodidad y fidelidad al entorno del servidor.

Extensiones recomendadas para este curso:

• ShellCheck: marca errores de shell mientras escribes (lo veremos a fondo en 08-05).
• shell-format: formatea scripts automáticamente.
• Bash Debug: permite ejecutar paso a paso.

Por último, define tu editor preferido para que otras herramientas (como crontab -e, que usaremos en el Módulo 7) lo respeten. En ~/.profile:

• Poner los alias en ~/.bash_profile. No aparecerán al abrir una pestaña de terminal, porque esa es una sesión no-login. Los alias y el PS1 van en ~/.bashrc.
• Crear un ~/.bash_profile y "perder" la configuración de ~/.profile. Bash lee solo el primero de ~/.bash_profile, ~/.bash_login, ~/.profile. Si creas el primero, el tercero deja de leerse.
• Escribir export PATH="~/veloz-ops/bin:$PATH". La virgulilla no se expande dentro de comillas dobles. Usa $HOME.
• Olvidar $PATH al reasignarlo. Escribir export PATH="$HOME/veloz-ops/bin" deja el sistema sin acceso a ls, grep ni nada. Si te ocurre, la sesión actual queda inservible pero se arregla abriendo una terminal nueva y corrigiendo el fichero; para recuperar la sesión rota puedes usar export PATH=/usr/bin:/bin provisionalmente.
• Espacios en alias ll = 'ls -lh'. En Bash, las asignaciones no admiten espacios alrededor del =.
• Editar ~/.bashrc y esperar que el cambio se aplique solo. Recarga con source ~/.bashrc o abre una terminal nueva.
• Consejo: antes de tocar ~/.bashrc, haz una copia (cp ~/.bashrc ~/.bashrc.bak). Un error de sintaxis ahí puede dejarte con una terminal que muestra errores en cada arranque.
• Consejo: si administras varios servidores, mantén tus dotfiles en un repositorio Git. En 08-04 veremos cómo.

Averigua y anota, en tu propia máquina:

1. La versión de Bash instalada y si soporta arrays asociativos (necesitas 4.0 o superior).
2. Tu shell de login configurado.
3. Cuántos directorios tiene tu PATH.
4. Si existen ~/.bashrc, ~/.bash_profile y ~/.profile.

Deja tu entorno listo para el curso:

1. Crea ~/veloz-ops con los subdirectorios bin, lib, etc y logs en un solo comando.
2. Añade ~/veloz-ops/bin al principio del PATH de forma permanente.
3. Define un alias ops que te lleve a ~/veloz-ops.
4. Cambia tu prompt para que muestre usuario, máquina y directorio actual.
5. Aplica los cambios sin cerrar la terminal y verifica que todo funciona.

Un compañero de Veloz Envíos define export API_TOKEN="abc123" únicamente en su ~/.bashrc. Después programa un script en cron que necesita esa variable, y el script falla diciendo que API_TOKEN está vacía.

1. Explica por qué falla.
2. Propón dos soluciones distintas.

Solución al Ejercicio 1

Interpretación: hay Bash 5.2, muy por encima del 4.0 necesario para arrays asociativos; el shell de login es Bash; el PATH tiene 6 entradas (tr convierte los : en saltos de línea y wc -l cuenta líneas); y existen ~/.bashrc y ~/.profile, pero no ~/.bash_profile, que es la configuración estándar de Ubuntu.

Solución al Ejercicio 2

La construcción cat >> fichero << 'EOF' ... EOF es un here-document: añade al final del fichero todo el texto hasta la marca EOF. Las comillas simples alrededor de 'EOF' son importantes: evitan que $HOME y $PATH se expandan ahora en lugar de quedar escritos literalmente en el .bashrc. Los here-documents se estudian en 05-05; también puedes hacerlo simplemente abriendo el fichero con nano ~/.bashrc y escribiendo las líneas a mano.

Solución al Ejercicio 3

1. Falla porque los scripts de cron se ejecutan en un shell no interactivo y sin login. Como vimos en la tabla, en ese modo Bash no lee ~/.bashrc ni ~/.bash_profile. De hecho, ~/.bashrc en Ubuntu empieza con una comprobación que aborta su ejecución si el shell no es interactivo. Por tanto API_TOKEN nunca llega a definirse en el entorno de cron.

2. Dos soluciones válidas:

   • Definir la variable dentro del propio script o en un fichero de configuración que el script cargue explícitamente, por ejemplo ~/veloz-ops/etc/veloz-ops.conf con un source al inicio. Es la más limpia y la que usaremos en el curso: el script no depende del entorno de quien lo lance.
   • Definirla en el propio crontab, ya que cron admite asignaciones antes de las líneas de tareas (API_TOKEN=abc123). Funciona, pero mezcla secretos con la programación de tareas.

   Como variante, podría usarse BASH_ENV apuntando a un fichero de entorno, pero es poco habitual y frágil. En general, la lección que hay que extraer es: un script no debe depender de la configuración interactiva del usuario. Lo veremos aplicado en 07-01.

Tu entorno ya está listo: sabes qué versión de Bash tienes y por qué importa, cómo conseguir un Bash moderno en Linux, macOS y Windows, y —lo más valioso a medio plazo— qué fichero de configuración se lee en cada situación, que es la raíz de la mayoría de los "a mí no me funciona". Además, ~/veloz-ops ya existe con sus cuatro directorios, su bin está en el PATH y tienes alias y prompt a tu gusto.

Con el terreno preparado, toca aprender a moverte por él. En la siguiente lección, Navegación Básica en la Línea de Comandos, recorrerás el árbol de directorios de Linux, entenderás la anatomía de un comando y explorarás por primera vez la infraestructura real de Veloz Envíos: /var/log/veloz, /srv/veloz/datos y tu propio ~/veloz-ops.