Antes de escribir una sola línea de código conviene entender qué es exactamente esa ventana negra con letras en la que tantos profesionales de sistemas, desarrollo y datos pasan buena parte de su jornada. Bash no es "la pantalla negra": es un programa concreto, con su historia, su sintaxis y su lugar bien definido dentro del sistema operativo. En esta lección descubrirás qué es un shell, por qué Bash se convirtió en el estándar de facto del mundo Unix y Linux, y cuáles son sus dos caras: la de intérprete interactivo con el que conversas y la de lenguaje de programación con el que automatizas. También conocerás a Veloz Envíos, la empresa ficticia que nos acompañará durante todo el curso y cuyos problemas reales iremos resolviendo lección a lección.

1. Qué es un shell y qué hace realmente
2. Bash dentro de la familia de shells Unix
3. Breve historia: de Thompson a Bourne Again
4. Por qué Bash sigue siendo el estándar de facto
5. Los dos usos de Bash: intérprete interactivo y lenguaje de scripting
6. Comparativa: Bash frente a otros shells
7. Dónde te encontrarás Bash en la vida profesional
8. Nuestro caso práctico: Veloz Envíos y el toolkit veloz-ops
9. Tus primeros comandos

Un shell (literalmente, "concha" o "caparazón") es un programa que actúa de intermediario entre tú y el núcleo del sistema operativo. Su trabajo se resume en un ciclo muy simple que repite una y otra vez:

1. Muestra un prompt (una invitación a escribir).
2. Lee la línea que tecleas.
3. La interpreta: decide qué comando quieres ejecutar y con qué datos.
4. Ejecuta ese comando y espera a que termine.
5. Muestra el resultado y vuelve al paso 1.

El nombre "caparazón" es muy descriptivo: el shell envuelve al kernel (el núcleo de Linux, que gestiona memoria, procesos, discos y red) y te ofrece una forma humana de pedirle cosas. Tú no hablas con el kernel directamente; le hablas al shell, y el shell traduce.

Conviene separar tres conceptos que los principiantes suelen confundir:

Es decir: abres una terminal, que arranca un shell (normalmente Bash), que a su vez pide servicios al kernel. Cuando alguien dice "ábreme una terminal y ejecuta este comando", en realidad te está pidiendo que se lo des a Bash.

Bash significa Bourne Again SHell, un juego de palabras: es "el shell Bourne otra vez" y a la vez suena a born again, "renacido". Ese nombre delata su linaje. En Unix existen dos grandes familias de shells:

• Familia Bourne (sh): el shell original de Unix escrito por Stephen Bourne. De aquí descienden ksh, bash, dash, zsh. Es la familia cuya sintaxis se estandarizó en POSIX y la que se usa para scripting serio.
• Familia C shell (csh, tcsh): sintaxis inspirada en el lenguaje C. Cómoda en su día para uso interactivo, pero desaconsejada para scripts desde hace décadas.

Bash pertenece a la primera familia y es compatible hacia atrás con sh: casi cualquier script escrito para el shell Bourne funciona en Bash sin cambios. A esa base Bash le añadió una enorme cantidad de extensiones propias que los profesionales llaman coloquialmente bashismos (arrays, [[ ... ]], expansión de llaves, sustitución de procesos...). Esas extensiones son potentes, pero conviene saber que no son portables a cualquier shell; volveremos sobre ello en la lección de portabilidad POSIX (08-07).

Una cronología mínima ayuda a entender por qué las cosas son como son:

El dato clave: Bash nació como software libre del proyecto GNU. Cuando Linux apareció en 1991, adoptó el conjunto de herramientas GNU, y Bash entró por la puerta grande como shell por defecto de prácticamente todas las distribuciones. Esa decisión histórica es la razón de que hoy, treinta y cinco años después, sigas necesitando aprenderlo.

Existen shells más modernos y en algunos aspectos más agradables. Aun así, Bash mantiene su posición por razones muy prácticas:

• Ubicuidad: está instalado en casi cualquier sistema Linux, en macOS, en los contenedores más comunes y en las imágenes de las nubes públicas. Si escribes un script en Bash, es muy probable que funcione en la máquina de destino sin instalar nada.
• Estabilidad: un script escrito en 2005 sigue funcionando hoy. En infraestructura, esa previsibilidad vale oro.
• Efecto red: la inmensa mayoría de la documentación, los tutoriales, las respuestas de foros y los ejemplos de los proveedores cloud están escritos en Bash.
• Es el pegamento del ecosistema Unix: Bash no intenta hacerlo todo; su trabajo es encadenar programas especializados (grep, awk, sort, curl) para resolver un problema. Ese modelo de composición sigue siendo extraordinariamente productivo.
• Está en la ruta crítica de la automatización: los Dockerfile, los pipelines de CI/CD, los systemd units, los crontab y los instaladores acaban ejecutando líneas de shell.

Dicho de otro modo: puedes elegir Zsh o Fish para tu comodidad diaria, pero tarde o temprano tendrás que leer y escribir Bash porque es la lengua franca de los servidores.

Esta distinción es fundamental y estructura todo el curso.

Es el uso conversacional: escribes un comando, pulsas Enter, ves el resultado, decides el siguiente. Es exploración, diagnóstico, trabajo puntual.

Aquí has hecho una pregunta ("¿quién soy?") y has obtenido una respuesta inmediata. En modo interactivo Bash te da comodidades como historial, autocompletado con el tabulador y un prompt personalizable. Todo eso lo veremos en las lecciones 01-02 y 02-06.

Es el uso programático: guardas una secuencia de comandos en un fichero de texto y lo ejecutas como un programa. Bash tiene entonces todo lo que esperas de un lenguaje: variables, condicionales, bucles, funciones, códigos de error.

No te preocupes todavía por la sintaxis: aún no sabes qué hace #!/usr/bin/env bash ni por qué hay un $( ). Todo eso se explica a partir del Módulo 3. Lo que sí debes retener es la idea:

Un buen profesional de Bash se mueve continuamente entre ambos mundos: prueba una idea de forma interactiva y, cuando funciona, la cristaliza en un script para no volver a hacerlo a mano. Ese es precisamente el viaje que haremos con Veloz Envíos.

Dos matices importantes que causan muchos problemas en la práctica:

• En Ubuntu y Debian, /bin/sh es dash, no Bash. Si escribes un script con bashismos y lo empiezas con #!/bin/sh, fallará con errores desconcertantes. La regla: si usas funciones de Bash, declara #!/usr/bin/env bash.
• En macOS, el /bin/bash del sistema es la versión 3.2 de 2007 por motivos de licencia (Apple no adopta la licencia GPLv3). Por eso los arrays asociativos, que llegaron en Bash 4, no funcionan ahí. Lo resolveremos en la lección 01-02.

No es un lenguaje que se use "por gusto": aparece porque es la vía de menor resistencia en estos escenarios.

• Servidores Linux: cuando entras por SSH a una máquina, lo que te recibe es un shell. Diagnosticar por qué un servicio no arranca o por qué se ha llenado el disco es trabajo de Bash.
• CI/CD: GitHub Actions, GitLab CI y Jenkins ejecutan sus pasos como líneas de shell. Un run: | de GitHub Actions es literalmente Bash.
• Contenedores Docker: cada RUN de un Dockerfile es una línea de shell, y los entrypoint.sh que preparan un contenedor antes de arrancar la aplicación son scripts de Bash.
• Cloud: los user-data de una instancia EC2, los scripts de arranque de una VM de Azure o GCP, y buena parte de la documentación de aws/gcloud/az son Bash.
• Ciencia de datos e IA: preparar datasets, mover ficheros, lanzar entrenamientos en lotes y encadenar herramientas suele hacerse con shell.
• Desarrollo diario: los scripts de un package.json, los Makefile y los git hooks acaban invocando shell.

En todos estos contextos, saber Bash es la diferencia entre "esperar a que alguien de sistemas me lo mire" y resolverlo tú mismo en cinco minutos.

A lo largo de este curso no aprenderás Bash con ejemplos abstractos, sino resolviendo los problemas de una empresa concreta.

Veloz Envíos es una compañía ficticia de reparto de última milla que opera en Valencia, Sevilla y Bilbao. Tú entras como responsable técnico de operaciones. Tu infraestructura es la siguiente:

El problema real que vamos a resolver es este. Cada mañana, alguien del equipo hace a mano lo siguiente:

1. Entra por SSH a srv-veloz-01.
2. Mira si el disco tiene espacio y si veloz-api está viva.
3. Busca los ERROR de las últimas 24 horas en app.log.
4. Cuenta cuántas peticiones devolvieron error 500 en acceso.log.
5. Abre envios.csv en una hoja de cálculo para contar incidencias por ciudad.
6. Copia todo en un correo y lo envía a operaciones.

Son unos cuarenta minutos diarios de trabajo repetitivo, propenso a errores y que nadie hace cuando esa persona está de vacaciones. Es el candidato perfecto a la automatización.

La solución que construiremos, pieza a pieza, se llama veloz-ops: un pequeño toolkit de scripts propios que vive en ~/veloz-ops/ y que al final del curso será capaz de generar ese informe solo, cada mañana, y avisar cuando algo va mal. Cada módulo aporta una pieza:

Guarda esta imagen mental: todo lo que aprendas tiene un destino concreto. No estamos coleccionando comandos, estamos construyendo una herramienta.

Terminemos tocando el teclado. Abre una terminal (si aún no sabes cómo, la lección 01-02 lo detalla) y prueba estos tres comandos.

echo es el comando más simple de todos: imprime en pantalla lo que le pasas. Parece trivial, pero es la base de los mensajes de un script, de los informes y de la depuración. Fíjate en la estructura: la palabra echo es el comando, y el texto entre comillas es su argumento. Las comillas agrupan varias palabras en un único argumento; sin ellas también funcionaría aquí, pero adquiere el hábito desde el principio (el porqué exacto se explica en 03-06).

Por defecto muestra la fecha en el formato del idioma del sistema. Pero acepta una opción de formato que empieza por +:

Aquí %Y es el año con cuatro dígitos, %m el mes y %d el día. Este formato AAAA-MM-DD no es un capricho: ordena alfabéticamente igual que cronológicamente, por lo que es el que usaremos para nombrar los ficheros de log e informes de veloz-ops. Un fichero llamado informe-2026-08-03.txt siempre queda en el sitio correcto al listar el directorio.

Responde con el nombre del usuario actual. En un servidor compartido como srv-veloz-01 es una de las primeras cosas que se comprueban, porque los permisos dependen de quién eres: no es lo mismo estar como joan que como root. Los permisos se tratan en profundidad en la lección 02-03.

Esa construcción $(comando) se llama sustitución de comandos: Bash ejecuta primero lo que hay dentro de los paréntesis y sustituye la expresión por su salida. Es uno de los mecanismos más útiles del shell y lo estudiaremos a fondo en 03-06; por ahora quédate con la intuición de que te permite meter el resultado de un comando dentro de un texto.

• Confundir la terminal con el shell. Cambiar de emulador de terminal (de GNOME Terminal a Alacritty, por ejemplo) no cambia tu shell. Si quieres saber cuál estás usando de verdad, tienes herramientas específicas que veremos en 01-02 y 01-04; no te fíes del aspecto de la ventana.
• Creer que "Linux" y "Bash" son sinónimos. Bash es un programa que corre sobre Linux, y puede correr también sobre macOS o Windows. A la inversa, un sistema Linux puede usar otro shell perfectamente.
• Escribir #!/bin/sh en un script con bashismos. En Ubuntu eso invoca dash y obtendrás errores del tipo [[: not found. Usa #!/usr/bin/env bash cuando uses funciones de Bash.
• Copiar comandos de internet sin entenderlos. Es la causa número uno de desastres en servidores. En la lección 01-05 aprenderás a verificar qué hace un comando antes de ejecutarlo.
• Pensar que Bash es "solo para administradores". Cualquier perfil técnico que trabaje con servidores, contenedores o pipelines lo necesita. Es una de las habilidades con mejor relación entre esfuerzo de aprendizaje y utilidad diaria.
• Consejo de método: no memorices comandos. Memoriza conceptos (qué es un shell, qué es una expansión, qué es un código de salida) y aprende a consultar la documentación. Un profesional consulta man a diario sin ningún complejo.

Sin ejecutar nada todavía, responde con tus palabras:

1. ¿Qué diferencia hay entre una terminal, un shell y el kernel?
2. ¿Por qué un script escrito para Bash puede fallar si lo ejecuta dash?
3. Cita tres lugares del mundo profesional donde te encontrarás Bash aunque no seas administrador de sistemas.

Escribe en la terminal un único comando que imprima exactamente este texto (con la fecha del día en que lo ejecutes):

Pistas: necesitas echo, la sustitución $(...) y date con el formato +%Y-%m-%d.

Para cada situación, indica qué shell elegirías y por qué:

1. Un script de arranque que debe funcionar en Debian, en Alpine Linux y en un router con BusyBox.
2. Tu shell diario de trabajo, en el que valoras el autocompletado inteligente.
3. Un script que debe correr en el pipeline de GitHub Actions de Veloz Envíos y que usa arrays.
4. Automatizar la creación de buzones de correo en un servidor Windows.

Solución al Ejercicio 1

1. La terminal es la ventana (o el dispositivo) que muestra texto y recoge tus pulsaciones; el shell es el programa que se ejecuta dentro de ella e interpreta lo que escribes; el kernel es el núcleo del sistema operativo, que gestiona hardware, memoria y procesos. La cadena es: tú → terminal → shell → kernel → hardware.
2. Porque dash implementa solo el estándar POSIX y no soporta las extensiones propias de Bash (arrays, [[ ... ]], expansión de llaves...). Si el script las usa, dash no las reconoce y falla. En Ubuntu y Debian, /bin/sh es precisamente dash, así que el error aparece en cuanto se usa #!/bin/sh por descuido.
3. Por ejemplo: los pasos run: de un pipeline de CI/CD (GitHub Actions, GitLab CI); las instrucciones RUN y los entrypoint.sh de contenedores Docker; los scripts de un package.json o un Makefile en desarrollo. También valdrían los user-data de instancias cloud o el preprocesado de datasets en ciencia de datos.

Solución al Ejercicio 2

Desglose de lo que ocurre:

1. Bash detecta $(date '+%Y-%m-%d') y lo ejecuta primero.
2. date devuelve 2026-08-03.
3. Bash sustituye toda la expresión por ese texto, quedando una única cadena.
4. echo imprime esa cadena resultante.

Las comillas dobles son necesarias aquí por dos motivos: mantienen el texto como un solo argumento y, a la vez, permiten que la sustitución $(...) se realice. Si hubieras usado comillas simples, verías literalmente $(date '+%Y-%m-%d') en pantalla. Esa diferencia se explica en detalle en la lección 03-06.

Solución al Ejercicio 3

1. sh POSIX (que en Alpine y BusyBox será ash, y en Debian dash). El requisito es máxima portabilidad, así que hay que renunciar a los bashismos. Es el caso que trataremos en 08-07.
2. zsh o fish, por su autocompletado y ergonomía superiores. Son decisiones de comodidad personal; no afectan a los scripts, que seguirán siendo Bash.
3. bash, con #!/usr/bin/env bash. Los arrays son una extensión de Bash y los runners de GitHub Actions lo llevan instalado por defecto.
4. PowerShell, porque el ecosistema de administración de Windows y Active Directory está construido sobre sus cmdlets y su modelo de objetos.

Ya sabes qué es Bash y por qué merece tu tiempo: es el shell que envuelve al kernel, el heredero directo del Bourne shell, y el estándar de facto en servidores, contenedores y pipelines. Has visto sus dos caras —conversar con el sistema en modo interactivo y automatizarlo en modo script—, cómo se sitúa frente a sh, dash, zsh, fish y PowerShell, y en qué momentos de tu vida profesional aparecerá. Y, sobre todo, ya conoces a Veloz Envíos y el problema concreto que resolveremos: esos cuarenta minutos diarios de informe manual que acabarán convertidos en el toolkit veloz-ops.

Para empezar a trabajar necesitas un entorno 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 creado. Eso es exactamente lo que harás en la siguiente lección, Configurando tu Entorno.