1. El punto de llegada
En el tema 1, la primera conversación con la terminal fueron cinco comandos que solo preguntaban cosas:
$ whoami
ana
$ date
lun 12 oct 2026 10:15:42 -03
$ pwd
/home/ana
$ echo "Hola, terminal"
Hola, terminal
$ uname -sr
Linux 6.8.0-45-genericEsta es una línea del proyecto del tema 42. Entonces habría sido ruido; ahora se lee de izquierda a derecha, como una frase:
$ awk '$9 == 404 {print $7}' acceso.log | sort | uniq -c | sort -rn | head -n 5 > rotos.txt| Pieza | Lo que ahora sabes que ocurre | Tema |
|---|---|---|
awk, sort, uniq, head | La shell busca cada nombre en los directorios de PATH, y lanza cinco procesos a la vez. | 3, 32 |
'$9 == 404 {print $7}' | Las comillas simples impiden que la shell toque el signo $: el programa llega intacto a awk, que elige las líneas por un campo y escribe otro. | 9, 30 |
| | La salida estándar de cada proceso está conectada a la entrada estándar del siguiente. Ninguno sabe que hay otros. | 22, 24 |
sort | uniq -c | sort -rn | Ordenar, contar los repetidos, ordenar por la cuenta: la respuesta a «¿cuál es el más frecuente?». | 26 |
> rotos.txt | La shell crea el archivo antes de ejecutar nada, con los permisos que deja la umask, y lo conecta a la salida del último proceso. | 18, 23 |
| Que no escriba nada | Es la señal de que todo salió bien. El código de salida, en $?, lo confirma. | 25 |
Entre una sesión y la otra no hay una lista de comandos memorizados: hay un modelo. Sabes qué es un proceso, qué es un archivo, quién expande un comodín, por dónde viaja un texto y quién tiene permiso para qué. Con eso, un comando que nunca viste deja de ser un misterio: tiene nombre, opciones y argumentos, lee de una entrada, escribe en una salida, y su página de manual dice el resto.
El programa del curso prometía cuatro habilidades que se suman. Estos son los temas que construyeron cada una:
2. El curso en nueve respuestas
Cada bloque respondió una pregunta. Estas son las respuestas, en una frase cada una:
| Bloque | La pregunta | La respuesta |
|---|---|---|
| 1. Primeros pasos en la consola Temas 1 a 5 | ¿Qué es esto, y cómo le hablo? | Una shell lee una línea, la divide en un comando con sus opciones y argumentos, lo ejecuta y espera la siguiente; el manual, el historial y la tecla Tab hacen el resto. |
| 2. Navegar el sistema de archivos Temas 6 a 10 | ¿Dónde estoy, y dónde está cada cosa? | En un único árbol que nace en /, donde todo se nombra con una ruta, cada directorio tiene un propósito, y la shell expande los comodines antes de que el comando los vea. |
| 3. Manipular archivos y directorios Temas 11 a 15 | ¿Cómo creo, cambio y guardo cosas? | Con comandos que no preguntan ni tienen papelera, sobre archivos que son un inodo con uno o más nombres; el texto se edita sin salir de la consola, y un directorio entero se empaqueta en un archivo. |
| 4. Usuarios, grupos y permisos Temas 16 a 21 | ¿Quién puede hacer qué? | Cada archivo tiene un dueño, un grupo y nueve permisos; el sistema compara con ellos la identidad del proceso, y sudo presta la de root para una orden. |
| 5. Redirecciones y tuberías Temas 22 a 25 | ¿Cómo hago que los comandos trabajen juntos? | Cada proceso tiene una entrada y dos salidas, que la shell puede conectar a un archivo o a otro proceso; y un código de salida, que permite encadenar decisiones. |
| 6. Filtrar y transformar texto Temas 26 a 31 | ¿Cómo le saco información a un texto? | Con filtros pequeños que hacen una sola cosa —ordenar, contar, cortar, buscar, sustituir, calcular—, y con las expresiones regulares, que describen la forma de lo que se busca. |
| 7. Procesos y entorno Temas 32 a 34 | ¿Qué está corriendo, y en qué condiciones? | Un árbol de procesos, donde cada hijo hereda una copia del entorno de su padre; se los gobierna con señales, y el entorno de la shell se configura en archivos que se leen al arrancar. |
| 8. Paquetes y estado del sistema Temas 35 a 40 | ¿Cómo mantengo la máquina? | Instalando desde repositorios, midiendo carga, memoria y disco, gobernando los servicios, leyendo sus registros, y llegando por la red a otras máquinas para hacer allí lo mismo. |
| 9. Integración y cierre Temas 41 a 43 | ¿Cómo dejo de repetirlo? | Guardando los comandos en un archivo con una primera línea, argumentos y un código de salida: un script, que es un comando más. |
3. Las ideas que sostienen todo
Los comandos se olvidan, y se vuelven a buscar en el manual. Estas diez ideas no se olvidan, porque explican por qué cada comando es como es. Si alguna no resulta evidente, el tema indicado es el que conviene repasar.
| Idea | Lo que explica | Tema |
|---|---|---|
| La shell transforma la línea antes de ejecutarla. Comodines, variables y sustituciones se resuelven primero; el comando recibe el resultado. | Por qué rm * no le pasa un asterisco a rm, para qué sirven las comillas, y por qué anteponer echo muestra lo que se va a ejecutar. | 9 |
| Cada programa hace una sola cosa. Y la hace para cualquier texto, sin saber de dónde viene. | Por qué hay tantos comandos pequeños, y por qué sort sirve igual para ventas, procesos o registros. | 26 |
| El texto es la interfaz universal. Los datos, la configuración y los registros son líneas de texto. | Por qué las mismas herramientas sirven para todo, y por qué un sistema se administra editando archivos. | 12, 13 |
| Todo proceso tiene tres canales. Una entrada, una salida y una salida de errores, que la shell puede reconectar. | Las redirecciones, las tuberías, por qué los mensajes de error no se mezclan con los datos, y por qué un script puede ser un filtro. | 22 |
| Todo comando termina con un código. Cero es éxito; cualquier otro número, un fallo. | &&, ||, set -e, y por qué el silencio es una buena noticia. | 25 |
| Un hijo recibe una copia, y no devuelve nada. El entorno se hereda de padre a hijo, en un solo sentido. | Por qué cd es un comando interno, por qué un script no cambia la terminal, para qué existen export y source. | 34 |
| Un archivo no es su nombre. Es un inodo; los nombres son entradas de un directorio que apuntan a él. | Los enlaces, por qué borrar depende del directorio y no del archivo, y por qué el espacio no vuelve mientras alguien lo tenga abierto. | 14 |
| El permiso se decide comparando identidades. La del proceso contra el dueño, el grupo y los otros, en ese orden. | Todos los Permission denied, y qué hace exactamente sudo. | 17, 19 |
| Hay un solo árbol. Los discos, la memoria y hasta el estado del kernel aparecen como directorios dentro de él. | Por qué no hay letras de unidad, qué es montar, y por qué cat puede leer la carga del sistema. | 8, 38 |
| La terminal no pregunta y no deshace. Hace lo que se le escribió, de inmediato. | La costumbre de mirar antes de actuar: ls antes de rm, una copia antes de editar, un simulacro antes de sincronizar. | 11 |
Las cinco primeras tienen nombre propio. Juntas se las conoce como la filosofía de Unix, y son la razón por la que una herramienta escrita en 1975 se combina sin esfuerzo con una escrita el año pasado. Nadie las diseñó para ti, y sin embargo son la causa de que aprender cuarenta comandos alcance para resolver miles de problemas: lo que se aprende no son los comandos, sino la manera de unirlos.
4. Los patrones que se repiten
A lo largo del curso, las mismas formas aparecieron con ropas distintas. Reconocerlas es lo que permite usar con confianza un comando que se ve por primera vez.
| Patrón | Dónde apareció |
|---|---|
| Las mismas letras, en todas partes. | -r es recursivo o inverso; -n, un número o un simulacro; -v, mostrar más; -h, unidades legibles; -f, forzar o un archivo; -i, preguntar o ignorar mayúsculas. Y --help, siempre. |
| Un comando con subcomandos. | apt install, systemctl status, ip address, snap list, journalctl con sus filtros: un programa, una palabra que dice qué hacer, y lo demás. |
| Ordenar, contar, ordenar. | sort | uniq -c | sort -rn, para las ventas del tema 26, los procesos del 32, los errores del journal en el 39 y todo el proyecto del 42. |
| Probar antes de comprometerse. | echo delante de un comando con comodines; apt install -s; rsync -n; sudo mount -a antes de reiniciar; sshd -t antes de recargar; bash -n antes de ejecutar. |
| Una copia antes de editar. | .bashrc, /etc/fstab, sudoers: se guarda el original, se cambia, se prueba, y recién entonces se cierra la sesión. |
Consultar es libre; modificar pide sudo. | apt show y apt install; systemctl status y systemctl restart; ip address y su configuración. |
| De lo general a lo particular. | df y después du; la carga y después top; systemctl status y después journalctl -u; la interfaz, la puerta de enlace, Internet, el nombre. |
| Lo de un programa se toca con ese programa. | Los paquetes, con apt; la caché, con apt clean; el journal, con journalctl --vacuum; un servicio, con systemctl, no con kill. |
/usr es del sistema; /etc, del administrador; el directorio personal, tuyo. | Dónde instala un paquete, dónde se configura un servicio, dónde va un script propio, y qué no borra una desinstalación. |
| La configuración se lee al arrancar. | source ~/.bashrc, systemctl restart, daemon-reload, cerrar la sesión y volver a entrar: cambiar un archivo no cambia lo que ya está en memoria. |
| Verificar después de transformar. | Contar las líneas antes y después de un sed; listar el contenido de un tar; comparar una suma de verificación; mirar $?. |
5. Los errores, ahora con explicación
En la terminal, un mensaje de error no es un reproche: es la respuesta más informativa que el sistema puede dar, y casi siempre dice exactamente qué pasó. Al comienzo del curso eran frases en inglés; ahora cada una remite a un mecanismo conocido.
| El mensaje | Lo que significa | Tema |
|---|---|---|
command not found | La shell recorrió los directorios de PATH y no encontró un programa con ese nombre: está mal escrito, no está instalado, o está en un directorio que no figura en la lista. | 3, 34 |
No such file or directory | La ruta no lleva a nada. Casi siempre es una ruta relativa interpretada desde un directorio que no era el que se creía. | 6 |
Permission denied | La identidad del proceso no tiene, en el trío que le corresponde, el permiso que la operación requiere; o falta el paso por un directorio del camino. | 17 |
Operation not permitted | No es cuestión de permisos del archivo: la operación está reservada a root, o al dueño. | 18, 19 |
Is a directory, Directory not empty | Se le dio un directorio a un comando que esperaba un archivo, o falta la opción -r. | 11 |
Un > solitario al comienzo de la línea | La shell espera que termines: quedó una comilla sin cerrar. Ctrl+C devuelve el indicador. | 5, 9 |
| La terminal «colgada», sin indicador | Un programa está leyendo de la entrada estándar, que es tu teclado. Ctrl+D le anuncia el final; Ctrl+C lo interrumpe. | 22 |
| Un archivo vacío donde había datos | La redirección > trunca el destino antes de ejecutar el comando. | 23 |
Unable to locate package | Ese nombre no está en la lista local de paquetes: hay que renovarla, o el paquete se llama de otro modo. | 35 |
No space left on device | Se acabó el espacio, o se acabaron los inodos. | 38 |
target is busy | Algo —a menudo, tu propia shell— tiene un directorio o un archivo abierto en ese sistema de archivos. | 38 |
Job for … failed | El servicio no pudo arrancar, y la causa está escrita en su registro. | 39 |
Connection refused | La máquina respondió que nadie escucha en ese puerto. | 40 |
Connection timed out | No hubo respuesta: la máquina no está, o algo descarta los intentos. | 40 |
bad interpreter | El kernel no encontró el programa que nombra la primera línea del script. | 41 |
| Ningún mensaje | Funcionó. | 1 |
La costumbre que resume la tabla es leer el mensaje entero, despacio, antes de buscar nada en Internet. Lleva el nombre del programa que se queja, el del archivo que no pudo usar, y la razón. Y cuando hay que buscarlo, LC_ALL=C delante del comando lo muestra en su versión original, que es la que encuentra respuestas.
6. La caja de herramientas
El inventario del curso, ordenado por lo que se quiere hacer. No es para memorizar: es para saber que la herramienta existe, y dónde está explicada.
| Para… | Herramientas | Temas |
|---|---|---|
| Pedir ayuda | man, --help, apropos, type, tldr | 3, 4 |
| Escribir menos | Tab, Ctrl+R, history, !!, alias | 5 |
| Orientarse | pwd, cd, ls, tree, stat, file | 6, 7, 12 |
| Encontrar un archivo | find, locate, los comodines | 9, 10 |
| Crear, copiar, mover y borrar | touch, mkdir, cp, mv, rm, ln | 11, 14 |
| Ver y editar | cat, less, head, tail, wc, nano, vim | 12, 13 |
| Empaquetar y comprimir | tar, gzip, zip, zcat, zgrep | 15 |
| Saber quién es quién | whoami, id, who, getent | 16 |
| Decidir quién puede qué | chmod, chown, umask, sudo, useradd, passwd | 17 a 21 |
| Conectar comandos | >, >>, <, 2>, |, tee, xargs, &&, ||, $( ) | 22 a 25 |
| Ordenar, contar y recortar | sort, uniq, cut, tr, paste, column | 26 |
| Buscar en un texto | grep y las expresiones regulares | 27, 28 |
| Transformar un texto | sed, awk | 29, 30 |
| Comparar y cruzar | diff, cmp, comm, join | 31 |
| Ver y gobernar procesos | ps, top, pgrep, jobs, fg, bg, kill, nohup | 32, 33 |
| Configurar la shell | export, env, source, PATH, PS1, .bashrc | 34 |
| Instalar y quitar programas | apt, dpkg, dnf, pacman, snap, flatpak | 35, 36 |
| Medir el sistema | uname, uptime, free, lscpu, vmstat, watch | 37 |
| Administrar el disco | lsblk, df, du, ncdu, mount, umount | 38 |
| Gobernar servicios y leer registros | systemctl, journalctl, logger | 39 |
| Usar la red | ip, ping, ss, curl, wget, ssh, scp, rsync | 40 |
| Automatizar | #!/bin/bash, $1, set -e, bash -x, shellcheck, crontab | 41 |
Son algo más de cien comandos. En el trabajo diario se usan veinte, y los demás se consultan. La diferencia entre quien conoce la terminal y quien no, no está en recordarlos: está en saber, ante un problema, que alguno lo resuelve, y en poder leer su manual.
7. Lo que quedó en tu equipo
El curso no fue solo lectura. Si hiciste los ejemplos, tu sistema tiene ahora varias cosas que antes no tenía, y que siguen siendo útiles:
| Qué | Dónde | Para qué sirve de aquí en más |
|---|---|---|
| Un directorio de práctica | ~/practica | Un lugar donde probar cualquier comando sin riesgo. Conviene conservar la costumbre, más que el directorio. |
| Una shell configurada a tu gusto | ~/.bashrc | Alias, historial ampliado, la función mkcd, un indicador propio. Es un archivo para llevar de máquina en máquina. |
| Comandos propios | ~/bin | respaldo, estado, frecuentes, informe-log: el comienzo de una colección que solo crece. |
| Un par de claves | ~/.ssh | Tu identidad ante cualquier servidor, y ante los sitios que alojan código. |
| Herramientas instaladas | El sistema | tree, htop, ncdu, tldr, mc, shellcheck, curl. |
| Un proyecto completo | ~/practica/proyecto | Un análisis de principio a fin, con su script: un modelo para el próximo archivo que haya que interrogar. |
Las tres primeras filas merecen un respaldo. Un .bashrc afinado durante años y un directorio de scripts propios son, para quien trabaja en la terminal, las herramientas más personales que tiene. El respaldo del tema 41 ya sabe guardarlos.
8. Lo que quedó sin ver
Un curso inicial elige. Varios temas se nombraron y se dejaron a un lado, a propósito, para no perder el hilo. Conviene saber cuáles son, porque todos aparecen pronto en el trabajo real.
| Quedó afuera | Lo que vimos de eso | Dónde se aprende |
|---|---|---|
| Programar en Bash: condiciones, bucles, funciones, leer del teclado, procesar opciones. | Scripts lineales, y la lista de lo que no pueden hacer, en el tema 41. | El curso siguiente, entero. |
awk y sed a fondo. awk es un lenguaje completo; sed tiene órdenes que no tocamos. | Lo necesario para filtrar, sumar y sustituir. | Sus manuales, y la práctica. |
vim más allá de sobrevivir. | Los modos, y las órdenes para editar y salir. | vimtutor, un tutorial interactivo que viene instalado. |
Un multiplexor de terminal: tmux o screen. | La mención, en los temas 33 y 40, de que es la herramienta para las sesiones largas en un servidor. | Su manual. Una tarde alcanza. |
Control de versiones con git. | Apareció como ejemplo de comando con subcomandos. | Un curso propio. Es el complemento natural de la terminal para quien programa. |
| Particionar y formatear discos. | Consultar, montar y desmontar. | El curso de Sistemas de Archivos. |
| Configurar la red y el cortafuegos. | Consultar y diagnosticar. | Los cursos de Redes y de Seguridad. |
| Contenedores. | El aislamiento de snap y flatpak, y la advertencia de que un contenedor no tiene kernel propio. | El curso de Virtualización y Contenedores. |
| Escribir un servicio propio. | Leer los archivos de unidad existentes. | La documentación de systemd, con lo aprendido en el tema 39. |
| Por qué funciona todo esto. Qué es, por dentro, un proceso, una tubería o un permiso. | El comportamiento, observado desde afuera. | Fundamentos de Sistemas Operativos, y los cursos intermedios. |
9. La ruta: trece cursos más
Este curso es el segundo de una serie de quince. Enseñó a usar el sistema. Los demás explican cómo funciona por dentro y cómo se lo programa, y casi todos retoman algo que aquí se vio desde la terminal.
Nivel inicial
| Curso | Se ocupa de | Lo tocamos en |
|---|---|---|
| 1. Fundamentos de Sistemas Operativos | Qué hace el kernel, y qué ocurre entre un programa y la máquina. Puede cursarse antes o después de este. | Temas 8, 22 y 32 |
| 3. Automatización con Scripts en Bash | Bash como lenguaje de programación: decidir, repetir y organizar. | Temas 25, 34, 41 y 42 |
| 4. Programación en C para Sistemas Operativos | El lenguaje en que están escritos el kernel y los comandos de este curso. | Temas 3 y 22 |
Nivel intermedio
| Curso | Profundiza en | Lo tocamos en |
|---|---|---|
| 5. Procesos e Hilos | Cómo se crea un proceso, qué es una señal por dentro, qué es un hilo. | Temas 32 y 33 |
| 6. Planificación de la CPU | Cómo decide el kernel quién usa el procesador, y qué mide la carga. | Temas 33 y 37 |
| 7. Concurrencia y Sincronización | Qué pasa cuando dos procesos quieren lo mismo a la vez, como en el bloqueo de apt. | Temas 33 y 35 |
| 8. Gestión de Memoria | La memoria virtual, la caché, el intercambio y el proceso que el kernel elige matar. | Temas 32 y 37 |
| 9. Sistemas de Archivos y Entrada/Salida | Los inodos, los bloques, el montaje y el camino de un dato hasta el disco. | Temas 8, 14 y 38 |
| 10. Comunicación entre Procesos | Qué es una tubería por dentro, y las demás maneras de conectar procesos. | Temas 22, 24 y 33 |
Nivel avanzado
| Curso | Profundiza en | Lo tocamos en |
|---|---|---|
| 11. Redes desde el Sistema Operativo | Interfaces, rutas, puertos y conexiones, vistos desde el kernel. | Tema 40 |
| 12. Seguridad en Sistemas Operativos | Los ataques, y los mecanismos que los contienen: permisos, privilegios, claves, registros. | Temas 16 a 21, 40 y 42 |
| 13. Virtualización y Contenedores | Cómo se construye una máquina dentro de otra, y un sistema aislado dentro de otro. | Temas 2, 36 y 37 |
| 14. Rendimiento, Depuración y Observabilidad | Medir, encontrar el cuello de botella y entender un sistema en producción. | Temas 37, 39 y 42 |
| 15. Construcción de un Sistema Operativo desde Cero | Escribir un kernel mínimo: arranque, interrupciones, memoria, procesos. | Temas 37 y 39 |
El orden recomendado es el de los números, pero la ruta no es una fila. La terminal es la herramienta de trabajo de todos los cursos que siguen: en cada uno habrá que compilar, ejecutar, medir y leer la salida de un comando, y eso ya lo sabes hacer. Es la razón por la que este curso está al principio.
10. El próximo paso
El curso que sigue es Automatización con Scripts en Bash. Empieza exactamente donde termina este: en un archivo con una primera línea, unos argumentos y una lista de comandos que se ejecutan de arriba abajo. Y le agrega lo que a esa lista le falta para ser un programa. Todo lo que allí se estudia ya pasó por delante de tus ojos, sin explicación:
| Lo vimos aquí, de pasada | Allí se estudia |
|---|---|
El if [ -d "$HOME/bin" ] de .profile, que leímos «sin saber programar» en el tema 34. | Las condiciones: if, case, y las pruebas sobre archivos, textos y números. |
El for i in 1 2 3 4 que lanzó cuatro procesos en el tema 37, y los bucles del generador del tema 42. | Los bucles: for, while, recorrer archivos, líneas y argumentos. |
La función mkcd del tema 34. | Las funciones: dividir un script en partes con nombre, con sus argumentos y su resultado. |
$1, "$@" y ${1:-valor}, del tema 41. | El procesamiento de argumentos y opciones, como las de un comando de verdad. |
set -e y exit 1. | El manejo de errores: detectar, informar, limpiar antes de salir. |
Las variables, y $(…). | Aritmética, arreglos y manipulación de textos sin llamar a otros programas. |
Una línea de crontab. | Scripts que corren solos: programados, sin terminal, dejando registro. |
La pregunta que apt y rm -i hacen antes de actuar. | Leer del teclado y de archivos: read. |
La diferencia es de naturaleza. Hasta aquí, cada línea que escribiste la decidiste tú, mirando el resultado de la anterior. En un script con condiciones y bucles, las decisiones las toma el programa: qué hacer si el archivo no existe, cuántas veces repetir, cuándo detenerse. Dejas de darle órdenes a la máquina, y empiezas a darle criterios.
Llegas a ese curso con la parte difícil hecha. Quien aprende a programar en Bash sin conocer la terminal tiene que aprender dos cosas a la vez: el lenguaje, y los cien comandos que el lenguaje pega entre sí. Tú ya tienes los comandos, las tuberías, las comillas y los códigos de salida. Lo que falta es poco, y es justamente lo que más rinde.
11. Cómo seguir practicando
La terminal se aprende como un idioma: usándola todos los días, aunque sea para poco. Algunas maneras de hacerlo, de menor a mayor esfuerzo:
- Hacer en la terminal lo que hoy haces con el ratón. Mover las descargas de la semana, buscar un archivo, ver cuánto lugar queda, actualizar el sistema. Al principio es más lento; al mes, no.
- Guardar lo que funciona. Cada línea que te costó armar va a un script en
~/bino a un alias. Es la costumbre del tema 41, y la que más rinde. - Leer una página de manual por semana. De un comando que ya usas. Siempre hay una opción que no conocías, y que ahorra una tubería.
- Terminar los ejercicios pendientes. Cada tema cerró con diez. Los del bloque 6 y los desafíos del tema 42 son los que más entrenan.
- Interrogar tus propios datos. El historial de la shell, los registros del sistema, una exportación del banco o de una planilla en CSV. Las preguntas propias enseñan más que las de cualquier curso.
- Administrar una máquina de verdad. Una placa pequeña en casa, una máquina virtual o el servidor más barato de la nube, al que se entre solo por
ssh. Mantenerla actualizada, con un servicio andando, pone en uso todo el bloque 8. - Jugar. Hay juegos de práctica que se resuelven desde la terminal, conectándose por
ssha un servidor y avanzando de nivel con los comandos de este curso. Bandit, del sitio OverTheWire, es el más conocido, y sus primeros veinte niveles son un repaso exacto de lo que vimos.
Para quien quiera un texto de consulta más amplio, hay cuatro libros que complementan bien este curso:
| Libro | Autor | Sirve para |
|---|---|---|
| The Linux Command Line | William Shotts | El mismo recorrido de este curso, con más extensión, y una segunda mitad sobre scripts. Está disponible gratuitamente en línea. |
| How Linux Works | Brian Ward | Lo que hay debajo de los comandos del bloque 8: arranque, dispositivos, red, servicios. |
| sed & awk | Dale Dougherty y Arnold Robbins | Las dos herramientas de los temas 29 y 30, completas. |
| UNIX and Linux System Administration Handbook | Evi Nemeth y otros | La referencia de quien administra sistemas. Para consultar, no para leer de corrido. |
Y antes que cualquier libro, la documentación que ya está en tu máquina: man bash es largo y árido, y contiene la respuesta exacta a toda pregunta sobre la shell. Ahora lo puedes leer.
12. El curso, en doce frases
- La shell es un programa que lee una línea, la interpreta, lanza otros programas y espera; la terminal es solo la ventana por la que se le habla.
- Un comando es un nombre, opciones y argumentos; la shell lo busca en
PATH, y su manual dice lo que hace. - Todo está en un único árbol de directorios, y se nombra con una ruta, absoluta o relativa al lugar donde se está.
- La shell expande comodines, variables y sustituciones antes de ejecutar; las comillas deciden qué se expande y qué no.
- Los comandos que modifican no preguntan ni deshacen: se mira antes, y se guarda una copia.
- Cada archivo tiene dueño, grupo y permisos, y el sistema los compara con la identidad de quien pide;
sudopresta, para una orden, la deroot. - Todo proceso lee de una entrada y escribe en dos salidas, que se pueden redirigir a un archivo o conectar a otro proceso con una tubería.
- Los filtros hacen una sola cosa cada uno, y encadenados responden casi cualquier pregunta sobre un texto.
- Cada comando termina con un código, y cada proceso hereda una copia del entorno de su padre: de ahí salen las decisiones y la configuración.
- El sistema se mantiene con paquetes que vienen de repositorios, servicios que alguien supervisa y registros que cuentan lo que pasó.
- Con
ssh, todo lo anterior vale para cualquier máquina del mundo. - Lo que funciona se guarda en un script, y deja de ser una línea para ser una herramienta.
13. Autoevaluación final
Estas preguntas no corresponden a un tema: cada una pide relacionar varios. Si puedes responderlas sin consultar, el objetivo del curso está cumplido.
1. Escribes ls *.txt | wc -l y pulsas Enter. Describe lo que ocurre hasta que aparece el número.
La shell divide la línea en dos comandos unidos por una tubería. Expande *.txt en la lista de nombres del directorio actual que coinciden. Busca ls y wc en los directorios de PATH, crea la tubería y lanza los dos procesos a la vez, con la salida estándar del primero conectada a la entrada estándar del segundo. ls recibe los nombres como argumentos y, al notar que su salida no es una terminal, los escribe uno por línea. wc cuenta las líneas que le llegan y escribe el número en su salida, que sigue siendo la terminal. La shell espera a que los dos terminen y vuelve a mostrar el indicador.
2. Un script hace cd /var/log y define una variable. Al terminar, la terminal sigue en el mismo directorio y la variable no existe. ¿Por qué, y qué dos maneras hay de que no sea así?
Porque el script se ejecutó en un proceso hijo, que recibió una copia del entorno, cambió lo suyo y terminó: un hijo no puede modificar a su padre. Para que los cambios queden en la shell actual, se ejecuta el archivo con source, o se convierte el trabajo en una función definida en .bashrc, que corre dentro de la shell.
3. cat informe.txt responde Permission denied. ¿Qué tres cosas verificas, y con qué comandos?
Quién soy, con id. Qué permisos tiene el archivo y de quién es, con ls -l informe.txt: según sea yo el dueño, miembro del grupo u otro, me toca uno de los tres tríos, y debe tener la r. Y si puedo atravesar cada directorio del camino, con ls -ld sobre ellos: sin la x en un directorio no se llega a lo que contiene, tenga los permisos que tenga.
4. ¿Por qué rm archivo puede borrar un archivo sobre el que no tienes ningún permiso, y por qué el espacio a veces no se libera?
Porque borrar es quitar un nombre de la lista de un directorio: lo que hace falta es permiso de escritura y de paso sobre el directorio, no sobre el archivo. Y el espacio se libera cuando al inodo no le queda ningún nombre y ningún proceso lo tiene abierto: si hay otro enlace duro, o un programa sigue escribiendo en él, los datos siguen ocupando lugar.
5. ¿Qué diferencia hay entre cmd > f 2>&1, cmd | tee f y cmd >> f?
El primero envía al archivo la salida y los errores, reemplazando su contenido, y no muestra nada. El segundo muestra la salida en pantalla y además la guarda en el archivo; los errores van solo a la pantalla. El tercero agrega la salida al final del archivo, sin borrarlo, y deja los errores en la pantalla.
6. Tienes un archivo CSV con una venta por línea: fecha, vendedor, importe. Escribe una línea que muestre los tres vendedores con más ventas, y otra que muestre el total vendido por cada uno.
cut -d, -f2 ventas.csv | sort | uniq -c | sort -rn | head -n 3 para la cantidad de ventas. Para los importes hay que sumar, y eso lo hace awk: awk -F, '{t[$2] += $3} END {for (v in t) print t[v], v}' ventas.csv | sort -rn.
7. ¿Qué diferencia hay entre grep 'a.c' archivo, grep 'a\.c' archivo y ls a*c?
En los dos primeros hay una expresión regular, que interpreta grep: en la primera el punto es un carácter cualquiera, y coincide con abc o a-c; en la segunda está escapado, y solo coincide con a.c. En el tercero hay un comodín, que expande la shell contra los nombres de archivo antes de ejecutar ls: el asterisco significa «cualquier cantidad de caracteres», que en una expresión regular se escribiría .*.
8. Un programa lanzado desde la terminal no responde a Ctrl+C. ¿Qué haces, paso a paso, y por qué en ese orden?
Desde otra terminal, se busca su PID con pgrep o ps. Se le envía kill PID, que manda la señal TERM: una petición que el programa puede atender cerrando sus archivos y terminando en orden. Si después de unos segundos sigue ahí, kill -9 PID, la señal KILL, que el kernel aplica sin avisarle. El orden importa porque la segunda no le da ocasión de guardar nada. Si es un servicio, no se usa kill sino systemctl stop.
9. Agregaste un alias a .bashrc y no funciona en la terminal abierta; tampoco funcionaría dentro de un script. ¿Por qué, en cada caso?
En la terminal abierta, porque Bash lee .bashrc al arrancar: hay que ejecutar source ~/.bashrc, o abrir otra. En un script, porque los alias pertenecen a las shells interactivas y no se heredan: un script corre en una shell no interactiva, que no lee .bashrc. Dentro de un script se escribe el comando completo.
10. ¿Qué diferencia hay entre apt update y apt upgrade, y entre systemctl start y systemctl enable?
apt update renueva la lista de paquetes disponibles y no instala nada; apt upgrade instala las versiones nuevas. systemctl start inicia un servicio ahora, hasta el próximo reinicio; enable hace que arranque solo en cada inicio, sin iniciarlo ahora. Los dos pares separan lo mismo: lo que se sabe o se dispone, de lo que efectivamente ocurre.
11. Te dicen que un servidor «está lento». ¿Qué miras, y en qué orden?
uptime, comparando la carga con nproc y mirando la tendencia de sus tres números. free -h, por la memoria disponible y el intercambio. vmstat 2, para saber si el recurso que falta es el procesador, el disco o la memoria. top, para encontrar el proceso. df -h, porque un disco lleno produce síntomas de cualquier clase. Y journalctl -p err -b, por si el sistema ya dijo lo que le pasa.
12. No puedes abrir un sitio web desde un servidor. ¿Cómo determinas si el problema es de la red, del DNS o del sitio?
De lo cercano a lo lejano. ip -br address e ip route, para ver que haya dirección y puerta de enlace. ping a la puerta de enlace, y a una dirección externa como 1.1.1.1: si fallan, es la red. ping al nombre del sitio: si la dirección externa responde y el nombre no se resuelve, es el DNS. Y curl -I al sitio: si todo lo anterior funciona y aquí hay un error o un tiempo agotado, el problema es del sitio, o de un puerto bloqueado.
13. ¿En qué se parecen un alias, una función y un script, y cuándo conviene cada uno?
Los tres le ponen nombre a un trabajo. El alias es un reemplazo de texto, para un comando con sus opciones habituales. La función es un grupo de comandos que corre dentro de la shell, y por eso puede cambiar su directorio o sus variables, y usar argumentos en cualquier posición. El script es un archivo que se ejecuta en un proceso aparte: lo puede usar cualquier programa, cualquier usuario, cron o ssh, y es lo indicado para todo lo que tenga más de unas pocas líneas.
14. Antes de ejecutar un comando que borra o reemplaza archivos, ¿qué precauciones aprendiste?
Mirar primero qué alcanzará, con ls o anteponiendo echo, para ver los comodines ya expandidos. Usar la opción de simulacro o de confirmación, si existe: -n, -i, -s. Guardar una copia de lo que se va a modificar. Comprobar en qué máquina y con qué usuario se está, leyendo el indicador. Y verificar el resultado después, en lugar de suponerlo.
15. Si tuvieras que explicarle a alguien, en un minuto, por qué vale la pena aprender la línea de comandos, ¿qué dirías?
No hay una única respuesta. Una posible: una interfaz gráfica permite hacer lo que alguien previó que querrías hacer; la línea de comandos, lo que tú necesites. Está hecha de piezas pequeñas que se combinan, de modo que con pocas se resuelven problemas que nadie anticipó. Lo que se hace una vez se puede guardar y repetir sin esfuerzo, sobre un archivo o sobre mil, en esta máquina o en otra que está a diez mil kilómetros. Y es la forma en que se trabaja en los servidores, que son casi todas las computadoras que existen.
Para terminar
- Vuelve al tema 1 y relee la primera conversación. Explica, para cada uno de los cinco comandos, de dónde saca su respuesta: qué variable, qué archivo o qué dato del kernel consulta.
- Elige las tres ideas de la sección 3 que te resulten menos claras, y repasa los temas indicados.
- Recorre la tabla de errores de la sección 5 y provoca cada uno a propósito, en
~/practicao en/tmp. - Abre tu historial con
history | frecuentes 20, el script del tema 41. ¿Qué comandos usas más? Convierte en alias o en script las dos líneas largas que más repetiste. - Toma una tarea que hagas todas las semanas con el ratón y resuélvela con un script de menos de veinte líneas. Anota lo que no pudiste hacer por no tener condiciones ni bucles: es la lista con la que empieza el curso siguiente.
Aquí termina Terminal y Línea de Comandos en Linux. La ventana negra del primer día sigue siendo una ventana negra, con un signo de pesos y un cursor que espera. Lo que cambió está de este lado de la pantalla: ahora sabes qué escribir, qué va a ocurrir cuando pulses Enter, y dónde mirar cuando no ocurra. Lo que sigue es enseñarle a la máquina a hacerlo sin ti.