En la lección anterior aprendiste a moverte por srv-veloz-01 y quedó una pregunta en el aire: por qué cd no puede ser un programa externo. Esa pregunta es la puerta de entrada a esta lección. Hasta ahora has usado el shell; ahora vas a entender qué ocurre exactamente entre que pulsas Enter y aparece el resultado. Este conocimiento no es teórico: explica por qué una variable definida en una tubería desaparece, por qué which a veces miente, por qué tu script "no encuentra" un comando que tú sí ves, y por qué source y ejecutar un fichero no son lo mismo. Son precisamente los errores que más tiempo hacen perder a quien programa en Bash sin este modelo mental.

1. Qué ocurre cuando pulsas Enter
2. Los tipos de comando y cómo distinguirlos
3. El PATH y el orden de búsqueda
4. Procesos padre e hijo: fork y exec
5. Subshells y por qué las variables no sobreviven
6. Entorno frente a variables de shell
7. $?: el código de salida
8. Poniéndolo todo junto en Veloz Envíos

Escribes ls -lh /var/log/veloz y pulsas Enter. Lo que parece instantáneo son en realidad seis fases bien definidas.

Veamos cada fase.

Bash lee la línea completa y la divide en palabras usando espacios, tabuladores y saltos de línea como separadores. También identifica los operadores especiales (|, >, &&, ;). De ls -lh /var/log/veloz salen tres palabras.

Aquí ya aparece la primera fuente de errores. Si un nombre de fichero contiene espacios, el troceado lo parte en dos:

Bash entiende dos argumentos, no uno. Por eso las comillas son importantes: ls "mi informe.txt". Todo el detalle está en 03-06.

Bash reescribe la línea antes de ejecutar nada. Sustituye:

Este punto es crucial y sorprende a mucha gente: el comando nunca ve los asteriscos. Cuando escribes ls *.log, quien expande el patrón es Bash, y ls recibe ya la lista de nombres. Puedes comprobarlo:

echo no sabe nada de comodines: recibió tres argumentos ya resueltos. El detalle completo de las expansiones se trata en 02-05 y 03-06; aquí basta con que sepas que ocurren antes.

Bash toma la primera palabra y busca en un orden estricto qué es. Lo veremos en la sección 2, porque es donde se concentran las sorpresas.

Si el comando resulta ser un ejecutable externo, Bash no puede "convertirse" en él (dejaría de existir tu shell). Hace dos cosas:

1. fork(): crea una copia de sí mismo, un proceso hijo.
2. exec(): el hijo reemplaza su propia imagen en memoria por la del programa a ejecutar.

El padre (tu Bash) se queda esperando con wait() a que el hijo termine. Por eso el prompt no vuelve hasta que el comando acaba, salvo que lo lances en segundo plano con &.

Cuando el hijo muere, devuelve un número entre 0 y 255. Bash lo guarda en $?. Es la base de todo el control de errores en scripting, y lo veremos en la sección 7.

No todo lo que escribes en el prompt es un programa. Bash reconoce cinco categorías, y las busca en este orden exacto:

El orden importa. Si defines una función llamada ls, se usará en lugar del /usr/bin/ls. Y si además defines un alias ls, el alias gana a la función.

type es un builtin de Bash y responde exactamente lo que Bash haría.

La opción -a muestra todas las coincidencias, en orden de prioridad. Es reveladora:

Existen dos echo: el builtin de Bash y el programa /usr/bin/echo de coreutils. Gana el builtin, siempre. Y no son idénticos: sus opciones difieren ligeramente entre sistemas, lo que provoca scripts que funcionan en una máquina y no en otra. Por eso en scripting profesional se prefiere printf, que es mucho más predecible (lo veremos en el Módulo 3).

Otro ejemplo muy ilustrativo con nuestro PATH de veloz-ops:

Aparecen dos rutas porque en los sistemas modernos /bin es un enlace simbólico a /usr/bin: es el mismo fichero visto de dos formas.

command -v imprime la ruta (o la definición) y devuelve un código de salida que indica si existe o no. Es la forma estándar y portable de comprobar disponibilidad en un script:

Este patrón lo usaremos de verdad en el Módulo 6, cuando veloz-ops necesite jq para hablar con la API.

Observa: which cd no imprime nada. Y ahí está el problema. which es un programa externo (en muchos sistemas, un script) que se limita a recorrer el PATH buscando ficheros. No sabe nada de builtins, funciones ni keywords, porque no puede ver el interior de tu shell.

La conclusión práctica: usa type -a para investigar de forma interactiva y command -v dentro de los scripts. Evita which. Un caso real de confusión: un compañero se queja de que time no existe porque which time no devuelve nada; en realidad time es una keyword de Bash, y type time lo aclara al instante.

Cuando Bash llega al paso 5 (ejecutable externo), recorre los directorios de PATH de izquierda a derecha y ejecuta la primera coincidencia.

Puntos importantes:

• La búsqueda se detiene en la primera coincidencia. Si hubiera un ls en ~/veloz-ops/bin, se ejecutaría ese y no el del sistema.
• El orden lo decides tú. Poner tu directorio delante da prioridad a tus herramientas; ponerlo detrás es más seguro.
• Bash cachea las rutas encontradas para no repetir la búsqueda. Si instalas un programa nuevo y Bash sigue diciendo que no existe, limpia la caché:

O consulta qué tiene memorizado:

Este es un problema real y frustrante: acabas de mover un script de sitio, lo ejecutas y Bash intenta lanzarlo desde la ruta antigua. hash -r lo resuelve en un segundo.

Si estás en ~/veloz-ops/bin y escribes informe.sh, Bash buscará en el PATH. Como el directorio actual no está en el PATH (y por seguridad no debe estarlo, según vimos en 01-02), no lo encontrará:

La solución es indicar una ruta explícita: ./informe.sh. En cuanto una palabra contiene una barra /, Bash deja de buscar en el PATH y la trata como ruta directa.

Con nuestra configuración de veloz-ops hay un matiz agradable: como añadimos ~/veloz-ops/bin al PATH, los scripts que pongamos ahí sí se podrán invocar por su nombre desde cualquier directorio, igual que ls. Es exactamente el efecto que buscábamos al montar el toolkit.

Cada proceso en Linux tiene un identificador (PID) y un padre (PPID). Tu shell también.

$$ es el PID del shell actual y $PPID el de su padre (normalmente el emulador de terminal o sshd).

Comprobemos la relación padre-hijo en directo:

El hijo tiene un PID distinto y su padre es tu shell. Esa es la mecánica del fork.

Cuando el hijo termina, todo lo que hizo en su propia memoria desaparece: variables, directorio actual, funciones. Solo sobrevive lo que escribió en disco o envió por su salida estándar. Este principio explica la mitad de los "misterios" de Bash.

Si usas exec explícitamente, Bash no crea un hijo: se reemplaza a sí mismo por el programa.

Se muestra la fecha y la terminal se cierra, porque tu shell ya no existe: se convirtió en date, y date terminó. Es una herramienta especializada, muy usada en los entrypoint.sh de contenedores Docker para que el proceso de la aplicación herede el PID 1 y reciba correctamente las señales de parada. No la uses a la ligera.

Un subshell es un proceso hijo que también es un Bash. Se crean en más situaciones de las que la gente sospecha.

Los paréntesis crearon un proceso hijo con una copia de las variables. Ese hijo modificó su copia y murió. El padre nunca se enteró. No es un fallo: es cómo funcionan los procesos en Unix. La información fluye del padre al hijo, nunca al revés.

Compara con las llaves:

Las llaves solo agrupan; no hay proceso nuevo. (Atención a la sintaxis: las llaves necesitan espacios interiores y un ; antes de la de cierre.)

Este es el error clásico, y lo planteamos con datos de Veloz Envíos. Queremos contar cuántas líneas de app.log son errores:

Cero, pese a que sí hay errores en el fichero. ¿Por qué? Porque el lado derecho de la tubería se ejecuta en un subshell. El bucle incrementó correctamente su propia copia de errores hasta, digamos, 47; después el subshell terminó y la copia se evaporó. El echo final lee la variable del shell padre, que sigue valiendo 0.

Hay tres soluciones, y conviene conocerlas todas:

La construcción < <(...) se llama sustitución de procesos: el grep se ejecuta aparte, pero el bucle while corre en el shell principal, así que la variable sobrevive. Se estudia a fondo en 05-05.

Con lastpipe, el último comando de la tubería se ejecuta en el shell actual. Funciona en scripts, pero no en sesiones interactivas normales.

Esta es la mejor: grep -c cuenta por sí mismo y la sustitución de comandos captura su salida. Cuando existe una herramienta que ya hace el trabajo, no lo hagas con un bucle. Es más rápido, más corto y no tiene el problema del subshell.

Ahora se entiende del todo lo que vimos en 01-02:

Y por eso cd tiene que ser un builtin: si fuera un programa externo, se ejecutaría en un hijo, cambiaría el directorio de ese hijo y moriría. Tu directorio no se movería un milímetro. Aquella pregunta pendiente de la lección anterior queda resuelta.

Hay dos clases de variables, y la diferencia es exactamente la de la sección anterior: qué se hereda.

• Variable de shell: existe solo en el shell actual. No se pasa a los hijos.
• Variable de entorno: se copia al entorno de cada proceso hijo.

El hijo no vio local_var porque nunca se exportó.

Variables de entorno que te encontrarás siempre:

Puedes definir una variable solo para un comando, sin tocar tu shell:

Esta sintaxis —asignación delante del comando, sin ;— es limpísima y muy usada en la práctica, por ejemplo para forzar un idioma en la salida de un comando:

Con LC_ALL=C la fecha sale en inglés. Es un truco importante en scripts: si tu script analiza la salida de un comando, fuerza LC_ALL=C para que no dependa del idioma del servidor. Un grep que busca "ago" fallaría en una máquina configurada en inglés.

Y para ejecutar algo con un entorno completamente limpio:

env -i borra todo el entorno. Es la mejor forma de simular las condiciones de cron, que ejecuta con un entorno mínimo. Si tu script funciona así, funcionará en cron. Lo aplicaremos en 07-01.

Todo comando devuelve al terminar un número entre 0 y 255:

• 0 significa éxito.
• Cualquier otro valor significa error.

Es al revés de lo que sugiere la intuición, pero tiene sentido: hay una única forma de acertar y muchas de fallar, así que cada valor distinto de cero puede identificar un tipo de fallo.

Códigos con significado convencional:

Comprobémoslos:

Un detalle que causa errores sutiles: $? se sobrescribe con cada comando, incluido el echo que la muestra.

La segunda lectura devuelve 0 porque es el resultado del echo anterior, que funcionó bien. Si necesitas el valor más de una vez, guárdalo inmediatamente:

Un caso especial que merece atención: en una tubería, $? es el código del último comando, no del primero.

Aunque grep falló, wc -l funcionó, así que la tubería declara éxito. Es una fuente de errores silenciosos en scripts. Se resuelve con set -o pipefail o consultando el array PIPESTATUS, temas de la lección 05-03.

Los códigos de salida son la base de &&, ||, if y del control de errores en general. Aquí solo era un primer contacto; el uso completo llega en 03-03 y 03-04.

Un escenario realista que combina todo lo anterior. Un compañero te dice: "He escrito un script veloz-estado que cuenta los errores del log, pero devuelve siempre 0 y encima cuando lo lanzo desde cron dice que no encuentra el comando."

Diagnostiquemos paso a paso.

Paso 1: ¿qué es realmente veloz-estado?

Existe y está en el PATH. Pero cron no lee tu ~/.bashrc (lo vimos en 01-02), así que su PATH no incluye ~/veloz-ops/bin. Simulemos el entorno de cron:

Reproducido. La solución: usar la ruta absoluta en el crontab, o definir el PATH dentro del propio script.

Paso 2: ¿por qué cuenta 0?

El script contiene esto:

Ya sabes el diagnóstico: el while corre en un subshell y total no sobrevive. La corrección:

Paso 3: ¿y si el fichero no existe?

Si el log no existe, grep devuelve 2 y total queda vacío. Guardar el código permite reaccionar. En 03-04 aprenderás a convertir eso en una condición, y en 05-03 a hacerlo de forma robusta.

Paso 4: verificación final del entorno

Este pequeño ritual —saber qué se va a ejecutar, con qué entorno y qué devolvió— es exactamente lo que distingue a alguien que depura con método de alguien que prueba cosas al azar.

• Usar which para comprobar si un comando existe. No ve builtins ni funciones y su comportamiento varía entre sistemas. Usa command -v en scripts y type -a de forma interactiva.
• Esperar que una variable modificada dentro de una tubería sobreviva. El lado derecho de | es un subshell. Usa < <(...), lastpipe, o mejor aún, una herramienta que ya haga el cálculo (grep -c, wc -l, awk).
• Ejecutar un fichero de configuración con ./config.sh esperando que defina variables. Necesitas source config.sh.
• Olvidar export y extrañarse de que el script hijo no vea la variable. Sin export, la variable no sale del shell actual.
• Leer $? demasiado tarde. Cualquier comando intermedio la sobrescribe, incluido un echo. Guárdala en cuanto la necesites.
• Suponer que una tubería falla si falla el primer comando. $? refleja el último. Usa set -o pipefail (05-03).
• Modificar un script, moverlo y que Bash siga ejecutando la versión antigua. Es la caché de rutas: hash -r.
• Dar por hecho que el entorno de cron es el tuyo. No lo es. Prueba tus scripts con env -i antes de programarlos.
• Consejo: cuando algo se comporte de forma inexplicable, hazte estas tres preguntas por orden: ¿qué es realmente este comando (type -a)?, ¿se está ejecutando en un subshell?, ¿qué variables hay en el entorno (env)?. Cubren la mayoría de los casos.
• Consejo: bash -x script.sh muestra cada línea tras las expansiones, antes de ejecutarla. Es la forma más rápida de ver el proceso de la sección 1 en acción. Lo formalizaremos en 05-03.

Sin ejecutar nada, predice qué tipo de comando es cada uno (alias, keyword, función, builtin o externo) y luego verifica con type -a:

1. cd
2. grep
3. [[
4. export
5. for
6. awk

Explica además por qué which cd no devuelve nada.

Este script pretende contar cuántos envíos con estado incidencia hay en /srv/veloz/datos/envios.csv, pero siempre imprime 0:

1. Explica exactamente por qué falla.
2. Corrígelo de dos formas distintas.
3. Indica cuál de las dos preferirías en veloz-ops y por qué.

Responde ejecutando lo necesario:

1. Define una variable CIUDAD="Bilbao" sin exportar y comprueba si un bash -c hijo la ve. Repite exportándola.
2. Ejecuta un comando que devuelva el código 127 y otro que devuelva el 2, y muestra ambos códigos.
3. Ejecuta grep 'ERROR' /fichero/que/no/existe | wc -l y explica por qué $? vale 0.
4. Comprueba si jq está instalado en tu sistema usando command -v dentro de un if.

Solución al Ejercicio 1

which cd no devuelve nada porque which es un programa externo que solo recorre los directorios del PATH buscando ficheros. cd no es un fichero: es código dentro del propio Bash. Un proceso externo no puede ver los builtins de su padre.

Solución al Ejercicio 2

1. Por qué falla: el bucle while está al lado derecho de una tubería, así que Bash lo ejecuta en un subshell. Ese subshell recibe una copia de incidencias, la incrementa correctamente y muere al terminar el bucle. El shell principal nunca ve el cambio, y el echo final lee su propia variable, que sigue valiendo 0. Es exactamente el problema de la sección 5.2.

2. Corrección A: sustitución de procesos (elimina la tubería, el bucle corre en el shell principal):

Nótese que aquí ni siquiera hace falta < <(...): como solo queríamos leer un fichero, basta con una redirección directa < fichero. El cat original era innecesario (es el llamado uso inútil de cat).

Corrección B: delegar el conteo en una herramienta:

O de forma más precisa, comprobando exactamente el quinto campo con awk (Módulo 6):

3. Cuál preferir: la B, con awk. Motivos: es una sola línea, no tiene el problema del subshell, y es mucho más rápida en ficheros grandes. Un bucle while read en Bash procesa unas pocas miles de líneas por segundo; awk procesa cientos de miles. Con un envios.csv de 11 MB la diferencia es de segundos frente a milisegundos. La regla general de Bash: el shell es para orquestar, no para procesar datos línea a línea. Lo veremos formalizado en 08-02.

Solución al Ejercicio 3

Sin export, CIUDAD es una variable de shell y no forma parte del entorno que hereda el hijo. Con export, pasa a formar parte del entorno y viaja en la copia.

127 es el código convencional para "comando no encontrado" y 2 para "uso incorrecto".

$? vale 0 porque en una tubería refleja el estado del último comando. grep falló con código 2, pero wc -l recibió una entrada vacía, contó cero líneas y terminó correctamente. Para detectar el fallo real:

El array PIPESTATUS guarda el código de cada elemento. La alternativa habitual en scripts es set -o pipefail, que hace que la tubería devuelva el primer código distinto de cero (05-03).

La redirección > /dev/null 2>&1 descarta tanto la salida normal como los errores: solo nos interesa el código de salida de command -v, no su texto. Las redirecciones se estudian en 02-04.

Ya tienes el modelo mental que sostiene todo lo que viene. Sabes que Bash trocea la línea, la expande, resuelve el comando en un orden estricto (alias → keyword → función → builtin → PATH) y, si es externo, hace fork y exec para ejecutarlo en un hijo. Entiendes por qué type -a es fiable y which no, cómo funciona la caché del PATH, y —lo más rentable de todo— por qué las variables no sobreviven a un subshell, lo que explica de una vez el comportamiento de las tuberías, los paréntesis, source y el propio cd. Y has tenido tu primer contacto con $?, la pieza sobre la que se construirá todo el control de errores del curso.

Con esto cierras el conocimiento fundamental del shell. Queda una habilidad transversal antes de pasar a los comandos: saber resolver dudas por tu cuenta. Ningún profesional recuerda todas las opciones de find ni el formato exacto de un crontab; lo que sabe es dónde mirarlo en diez segundos. En la siguiente lección, Encontrar Ayuda: man, help y --help, aprenderás a leer páginas de manual, a distinguir cuándo usar man y cuándo help, y a verificar comandos peligrosos antes de ejecutarlos en srv-veloz-01.