Terminal, consola y shell

1. Dos maneras de hablar con una computadora

Hay dos formas de pedirle algo a una computadora. La primera es la que todos conocemos: una interfaz gráfica, con ventanas, iconos y menús. Las opciones están a la vista, y se elige señalando con el ratón o con el dedo. La segunda es una interfaz de línea de comandos: no hay nada que señalar, y lo que se quiere se escribe.

La diferencia no es de aspecto, sino de naturaleza. Con una interfaz gráfica se elige entre lo que alguien previó; con una línea de comandos se dice lo que se quiere. Un ejemplo lo aclara. Supón que en una carpeta hay cientos de archivos y quieres saber cuántos son fotos en formato JPG.

$ ls *.jpg | wc -l
312

Esa línea se lee así: «lista los archivos cuyo nombre termina en .jpg y cuenta cuántas líneas tiene esa lista». Todavía no importa entender cada símbolo; lo aprenderás en los temas 7, 9 y 24. Importa notar que la respuesta se obtuvo describiendo la tarea, no ejecutándola a mano.

Ninguna de las dos formas es mejor en todo. Para retocar una fotografía o explorar un programa desconocido, la interfaz gráfica gana con facilidad. Para las tareas que se repiten, que involucran muchos archivos o que deben poder explicarse y automatizarse, gana la línea de comandos. Y esas son, precisamente, las tareas de quien programa.

2. Qué es una línea de comandos

Una interfaz de línea de comandos (CLI, por Command-Line Interface) es una forma de usar una computadora en la que el usuario escribe órdenes como texto, una por línea, y recibe la respuesta también como texto.

El funcionamiento es un ciclo de cuatro pasos, que se repite mientras dure la sesión:

1. El sistema muestra un indicador, una breve marca que significa «estoy listo, escribe». esperar
2. Escribes una línea y pulsas Enter. Hasta ese momento no ocurre nada: puedes corregir lo que quieras. leer
3. El sistema interpreta la línea y hace lo que pide. Casi siempre, ejecutar un programa. ejecutar
4. Muestra el resultado, si lo hay, y vuelve al primer paso. mostrar

Es una conversación por turnos: una pregunta, una respuesta, y de nuevo el indicador. Esa simplicidad es la base de todo lo demás. Como las órdenes son texto, se pueden guardar en un archivo, enviar por correo, pegar en un documento o hacer que las escriba otro programa. Y como las respuestas también son texto, la respuesta de una orden puede servir de entrada para la siguiente.

3. Cuatro palabras que se confunden

«Abre una terminal», «escríbelo en la consola», «es un comando de la shell», «usa la línea de comandos». En la conversación diaria las cuatro expresiones se usan como si fueran lo mismo, y casi nunca hay problema en hacerlo. Pero designan cosas distintas, y distinguirlas evita muchas confusiones más adelante.

La distinción que importa es la última. La terminal, en cualquiera de sus formas, es el medio: solo muestra letras y transmite teclas, y no sabe qué significa nada de lo que pasa por ella. La shell es el interlocutor: un programa que se ejecuta dentro de la terminal y entiende lo que escribes. La «línea de comandos», por último, no es un programa: es la forma de trabajar, y también el nombre de la línea que estás escribiendo.

Una consecuencia práctica de esta separación es que las piezas son intercambiables. Se puede cambiar de emulador de terminal —hay decenas, con distintos colores, pestañas y tipos de letra— y seguir usando la misma shell. Y se puede cambiar de shell sin cambiar de terminal. Cuando algo no se ve bien, el problema suele ser de la terminal; cuando un comando no se entiende, es asunto de la shell.

4. De dónde vienen los nombres

El vocabulario de la terminal es una colección de fósiles. Saber de dónde viene cada nombre hace que dejen de parecer arbitrarios.

En los años sesenta, una computadora ocupaba una sala y costaba una fortuna. Para que varias personas pudieran usarla a la vez se le conectaban teletipos: máquinas de escribir eléctricas, pensadas originalmente para enviar telegramas. Lo que el usuario tecleaba viajaba por un cable hasta la computadora, y la respuesta volvía y se imprimía, letra por letra, en un rollo de papel. Ese aparato, que estaba en el extremo del cable, era la terminal.

En los años setenta, el papel se reemplazó por una pantalla, y aparecieron las terminales de video. Seguían siendo aparatos sin inteligencia propia: mostraban los caracteres que recibían y enviaban los que se pulsaban. La más influyente fue la VT100, de 1978, cuyo modo de funcionar se convirtió en norma.

Cuando las computadoras personales tuvieron pantallas gráficas, ya no hizo falta un aparato aparte. Bastó un programa que dibujara una ventana y se comportara como una de aquellas terminales: un emulador de terminal. Por eso lo que abres hoy imita, con bastante fidelidad, a una máquina de 1978.

La historia explica también la propiedad más útil de todo el sistema. Como la terminal nació para funcionar a través de un cable, nunca dependió de estar junto a la computadora. Hoy el cable es Internet, y la misma interfaz permite manejar un servidor que está en otro continente exactamente igual que el equipo que tienes delante.

Si te interesa el contexto completo, el curso anterior de la ruta lo desarrolla en Historia y evolución de los sistemas operativos.

5. La shell: un programa como los demás

La shell no es una parte especial ni privilegiada del sistema operativo. Es un programa corriente, un archivo ejecutable como cualquier otro, cuyo trabajo consiste en leer líneas y ejecutar lo que piden.

Una shell, o intérprete de comandos, es un programa que muestra un indicador, lee una línea escrita por el usuario, la interpreta y ejecuta el comando correspondiente. Además es un lenguaje de programación, con variables, condiciones y bucles.

Que sea un programa común tiene una consecuencia: puede haber varias, y cada usuario puede elegir la suya. Estas son las que vas a encontrar nombradas:

Para saber qué shell estás usando y cuáles hay instaladas:

$ echo $SHELL                       # la shell asignada a tu usuario
/bin/bash
$ cat /etc/shells                   # las shells instaladas en el sistema
# /etc/shells: valid login shells
/bin/sh
/usr/bin/sh
/bin/bash
/usr/bin/bash
/usr/bin/dash
$ bash --version | head -1
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)

Hay algo que conviene tener claro desde ahora, porque aclara mucho de lo que viene. La shell conoce por sí misma muy pocos comandos. La gran mayoría —ls, cp, grep, cat— son programas independientes, guardados como archivos en el disco, que la shell se limita a buscar y poner en marcha. Por eso esos comandos funcionan igual en Bash, en zsh o en cualquier otra shell: no pertenecen a ninguna. Lo vemos en detalle en el tema 3.

6. Por qué Bash

El nombre es un juego de palabras: Bourne Again SHell, «la shell de Bourne, otra vez», que en inglés suena igual que «renacida». Fue escrita en 1989 por Brian Fox para el proyecto GNU, como reemplazo libre de la shell original de Unix. De las opciones de la tabla, es la que usaremos en todo el curso, por cuatro razones:

Si tu equipo usa otra shell —por ejemplo zsh, en una Mac— podrás seguir casi todo el curso sin cambios. Cuando algo sea propio de Bash, lo indicaremos.

7. Leer el indicador

Lo primero que muestra una terminal al abrirse es el indicador, o prompt: el texto que precede al cursor. No es un adorno. Es la shell diciendo «estoy lista», y de paso informando dónde estás y quién eres. En la mayoría de los sistemas tiene esta forma:

ana@equipo:~/proyecto$ ls -l
│   │      │         │ └─ el comando que escribes
│   │      │         └─ $ si eres un usuario común; # si eres el administrador
│   │      └─ el directorio en que estás; ~ es tu directorio personal
│   └─ el nombre del equipo
└─ tu nombre de usuario

Cada parte responde una pregunta que conviene poder contestar antes de ejecutar cualquier cosa:

El indicador se puede personalizar, y en algunos sistemas muestra otra cosa, pero estas cuatro piezas son las habituales. Acostumbrarse a mirarlo antes de pulsar Enter es el primer hábito de quien trabaja bien en la consola.

8. Una primera conversación

Veamos unos turnos de esa conversación. Son comandos inofensivos, que solo preguntan cosas:

$ whoami                            # ¿con qué usuario estoy?
ana
$ date                              # ¿qué día y hora es?
lun 12 oct 2026 10:15:42 -03
$ pwd                               # ¿en qué directorio estoy?
/home/ana
$ echo "Hola, terminal"             # repite lo que le digo
Hola, terminal
$ uname -sr                         # ¿qué sistema operativo es?
Linux 6.8.0-45-generic

Aun sin conocer los comandos, la sesión ya muestra las reglas del juego:

• Un comando, una respuesta, y otra vez el indicador. Que el indicador reaparezca significa que el comando terminó.
• Los nombres son abreviaturas. pwd viene de print working directory; whoami, de «¿quién soy?». Nacieron cortos porque se tecleaban en máquinas lentas, y quedaron así.
• Algunos comandos aceptan modificadores. En uname -sr, el -sr le pide una parte concreta de la información. Es el asunto del tema 3.
• Las mayúsculas cuentan. date es un comando; Date y DATE no existen. Lo mismo vale para los nombres de archivo.

Hay dos reglas más, que desconciertan al principio y conviene conocer de antemano:

$ mkdir pruebas                     # crea un directorio…
$                                   # …y no dice nada
$ fecha
fecha: command not found

El silencio tiene una razón práctica. Los comandos están pensados para combinarse, y un comando que añadiera frases de cortesía a su salida ensuciaría la entrada del siguiente.

9. Qué ocurre al pulsar Enter

Vale la pena tener, desde el comienzo, una imagen de lo que pasa entre que pulsas Enter y aparece la respuesta. No hace falta más que esto:

1. La shell separa la línea en palabras. La primera es el nombre del comando; las demás, lo que se le pasa. shell
2. Busca un programa con ese nombre en una lista de directorios del sistema. Si no lo encuentra, responde command not found. shell
3. Le pide al sistema operativo que lo ejecute, y se queda esperando. sistema operativo
4. El programa hace su trabajo y escribe su resultado, que la terminal muestra. el comando
5. El programa termina. La shell retoma el control y muestra el indicador otra vez. shell

Tres ideas de este recorrido reaparecerán en todo el curso. La shell es un intermediario: quien hace el trabajo es el programa. Mientras ese programa se ejecuta, la shell espera, y por eso no puedes escribir otro comando hasta que termine. Y lo que ves en pantalla lo escribe el programa, no la shell.

El detalle completo de este recorrido —procesos, descriptores, llamadas al sistema— es el tema La shell: qué ocurre cuando ejecutas un comando del curso anterior. Para este curso basta con la versión de cinco pasos.

10. Por qué sigue vigente

La línea de comandos tiene más de cincuenta años. Sobrevivió a las interfaces gráficas, a la web y a los teléfonos, y hoy se usa más que nunca. No es nostalgia: hay cosas que hace mejor que cualquier alternativa.

Sería deshonesto presentarlo como una ventaja sin costos. La línea de comandos tiene dos inconvenientes reales:

• No se descubre sola. Una interfaz gráfica muestra lo que se puede hacer; una terminal vacía no sugiere nada. Hay que saber de antemano qué escribir, o saber dónde buscarlo. Por eso el tema 4 está dedicado a encontrar ayuda.
• No perdona. No hay papelera ni «deshacer». Un comando que borra, borra. Lo veremos al llegar al tema 11, y con los hábitos de la sección 13.

La conclusión razonable no es abandonar las interfaces gráficas, sino sumar la otra herramienta. La mayoría de quienes programan usan las dos todo el día: un editor gráfico para escribir código, y una terminal a su lado para todo lo demás.

11. Un ejemplo que lo resume

La composición se entiende mejor viéndola. Supón que el disco se está llenando y quieres saber qué ocupa más espacio en tu directorio. Con un administrador de archivos habría que abrir carpeta por carpeta. En la terminal:

$ du -sh * | sort -rh | head -5
1,2G	videos
310M	fotos
48M	proyecto
6,1M	manual.pdf
12K	notas.txt

La línea tiene tres comandos, unidos por el símbolo |, que se llama tubería y hace que la salida de uno pase al siguiente:

Ninguno de los tres comandos fue escrito para esta tarea. du no sabe ordenar, sort no sabe nada de discos, y head no sabe qué son los números que deja pasar. Cada uno hace su parte, y el conjunto resuelve un problema que ninguno resuelve solo. Cambiando un número se obtienen los diez mayores; reemplazando el primer comando por otro, la misma idea ordena otra cosa.

No hace falta entender ahora cada opción: son el contenido de los temas 24, 26 y 38. Lo que sí conviene llevarse es la manera de pensar. En la terminal no se busca «el comando que hace lo que necesito». Se descompone la tarea en pasos simples, y se encadenan las herramientas que hacen cada paso.

12. Dónde vas a encontrar una terminal

Saber usar la consola no es una habilidad reservada a quien administra servidores. Aparece en casi todos los puntos del trabajo de desarrollo:

Y no solo en Linux. macOS es un sistema de la familia Unix, y su aplicación Terminal ofrece los mismos comandos. Windows incluye WSL, un sistema Linux completo que se ejecuta junto al propio Windows. Lo que aprendas aquí sirve en los tres.

13. Cómo se aprende, y qué puede salir mal

La terminal se aprende como un idioma: con un vocabulario pequeño al principio, y usándolo. Nadie memoriza todos los comandos ni todas sus opciones. Lo que se adquiere, con la práctica, es una estructura: saber qué clase de herramienta existe para cada clase de problema, y dónde consultar el detalle. Algunas recomendaciones:

• Escribe los comandos, no los copies. Teclear obliga a mirar cada parte, y es como se fija. Copiar y pegar deja la sensación de haber entendido.
• Modifica los ejemplos. Cambia una opción, quita una parte, observa qué pasa. Cada ejemplo del curso es un punto de partida.
• Lee los mensajes de error. Son breves y casi siempre dicen exactamente qué falló. Ignorarlos y probar otra cosa al azar es el hábito que más demora el aprendizaje.
• Usa la terminal para tareas reales. Mover unos archivos, buscar algo, ver cuánto espacio queda. Un comando usado para algo que necesitabas se recuerda.

Queda la pregunta que casi todos se hacen al empezar: ¿puedo romper algo? La respuesta honesta es que sí, pero mucho menos de lo que se teme, y con pocas precauciones el riesgo es mínimo.

Y estos son los hábitos que cubren el resto:

1. Mira el indicador antes de pulsar Enter. Quién eres, en qué equipo y en qué directorio.
2. Relee los comandos que borran o sobrescriben. En la terminal no hay papelera. Lo que se borra no vuelve.
3. No ejecutes como administrador lo que no entiendes. El administrador no tiene las protecciones de la tabla. Vemos cuándo y cómo usar ese privilegio en el tema 19.
4. No pegues comandos de Internet sin leerlos. Si no puedes explicar qué hace cada parte, todavía no es momento de ejecutarlo.
5. Si un comando no termina, pulsa Ctrl+C. Lo interrumpe y devuelve el indicador. Es la salida de emergencia, y no daña nada.

14. El mapa del curso

Los 43 temas están ordenados para que cada bloque use lo aprendido en los anteriores. Cada uno responde una pregunta:

Los bloques 5 y 6 son el corazón del curso: ahí la terminal deja de ser una manera incómoda de hacer lo que ya hacías con el ratón y se convierte en una herramienta que hace cosas nuevas. Los cuatro primeros construyen lo necesario para llegar. En el tema 2 preparamos el entorno y abrimos la primera sesión.

15. Resumen

• Una interfaz de línea de comandos es una conversación por turnos: el sistema muestra un indicador, se escribe una orden, se ejecuta y se muestra el resultado.
• La terminal es el medio, que muestra texto y envía teclas. La shell es el programa que interpreta lo que se escribe.
• Lo que hoy se abre en el escritorio es un emulador de terminal: un programa que imita a las terminales físicas de los años setenta.
• La shell es un programa común, y hay varias. Bash es la más extendida en Linux, y la que usa este curso.
• La mayoría de los comandos no pertenecen a la shell: son programas independientes, que la shell busca y ejecuta.
• El indicador informa quién eres, en qué equipo, en qué directorio y con qué privilegios. Conviene mirarlo antes de cada comando.
• Un comando que termina sin decir nada tuvo éxito. Los errores se informan con un mensaje breve.
• La línea de comandos sigue vigente porque sus órdenes se componen, se repiten, se automatizan, se comunican y funcionan a distancia.
• Sus inconvenientes son que no sugiere qué escribir y que no tiene «deshacer».
• En la terminal no se busca un comando para cada tarea: se descompone la tarea en pasos y se encadenan herramientas simples.
• Como usuario común, los permisos limitan el daño de un error. Mirar el indicador y releer los comandos que borran cubre el resto.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Averigua qué emulador de terminal trae tu sistema y cómo se abre. En Linux suele haber un atajo: Ctrl+Alt+T. En macOS se llama Terminal; en Windows, Terminal o PowerShell.
2. Si ya tienes una terminal de Linux o de macOS, ejecuta los cinco comandos de la sección 8 y compara las respuestas con las del ejemplo.
3. Mira tu indicador e identifica cada una de sus partes con la figura de la sección 7. ¿Muestra las cuatro?
4. Ejecuta echo $SHELL. ¿Qué shell usas? Si no es Bash, anótalo: lo tendremos en cuenta en el tema 2.
5. Escribe a propósito un comando que no exista y lee el mensaje. Luego escribe Date, con mayúscula. ¿Qué ocurre?
6. Piensa en tres tareas que hagas con frecuencia en tu computadora y que impliquen repetir la misma acción muchas veces. Anótalas: al terminar el curso podrás resolverlas con una línea.
7. Describe con palabras, paso a paso, cómo contarías en una interfaz gráfica cuántos archivos PDF hay en una carpeta. Compáralo con la línea de la sección 1.