Terminal, shell y CLI: tres conceptos que no son lo mismo

Cuando abres una ventana negra y empiezas a escribir comandos, en realidad están ocurriendo tres cosas distintas al mismo tiempo, manejadas por tres piezas de software diferentes. Mezclarlas no es un error grave cuando estás aprendiendo, pero entender la diferencia te va a ayudar cada vez que algo no funcione como esperas.

La terminal —más precisamente, el emulador de terminal— es el programa que dibuja esa ventana en tu pantalla. Se encarga de mostrar texto, capturar lo que escribes en el teclado y enviar señales cuando pulsas cosas como Ctrl+C. Históricamente, una terminal era un aparato físico: una pantalla y un teclado conectados por cable a un ordenador central. Hoy ese hardware ya no existe en el escritorio, pero el software lo imita fielmente, de ahí el nombre “emulador”. En GNOME —el entorno de escritorio que incluye Debian por defecto— ese programa se llama gnome-terminal. Hay otros: xterm, alacritty, kitty, tilix. Todos hacen lo mismo a nivel conceptual: son ventanas que saben mostrar texto y capturar teclado.

La shell es el programa que vive dentro de esa ventana y que realmente interpreta lo que escribes. Cuando tecleas ls -la y pulsas Enter, no es la terminal quien entiende ese comando: es la shell. Ella lo analiza, lo ejecuta, y devuelve el resultado a la terminal para que lo muestre. En Debian, la shell predeterminada para los usuarios es Bash (/bin/bash). Existen otras —zsh, fish, dash— con sintaxis y funcionalidades distintas. La shell es un programa como cualquier otro; puedes cambiarla, instalar varias, o incluso ejecutar una dentro de otra.

La CLI (del inglés Command Line Interface, interfaz de línea de comandos) no es un programa concreto: es un paradigma de interacción. Es la idea de que controlas el sistema escribiendo texto en lugar de hacer clic en botones. Se opone a la GUI (Graphical User Interface). Muchos programas tienen CLI —git, apt, ffmpeg— y no necesitan terminal ni shell para existir como concepto; simplemente se invocan con texto y responden con texto.

¿Por qué importa distinguirlos? Porque cuando algo falla, el error puede estar en capas distintas. Si la ventana no muestra colores correctamente, el problema está en el emulador de terminal y en la variable TERM. Si un comando no se encuentra, el problema está en la shell y en su PATH. Si un programa no acepta cierta opción, el problema está en la CLI de ese programa. Confundirlos te lleva a buscar la solución en el lugar equivocado.

# Averigua qué emulador de terminal estás usando
# (funciona desde cualquier terminal gráfica en X11/Wayland)
echo $TERM

# Averigua qué shell está ejecutando este proceso
echo $SHELL        # shell configurada para tu usuario en /etc/passwd
echo $0            # shell que está corriendo ahora mismo (puede diferir)

# Comprueba la ruta absoluta del ejecutable de tu shell actual
which bash
which zsh          # si lo tienes instalado

# Mira qué shell tiene asignada tu usuario en el sistema
grep "^$(whoami):" /etc/passwd

# Abre una instancia de zsh dentro de bash, sin cambiar tu shell permanente
# (solo para ver que son programas independientes que puedes anidar)
# zsh      # descomenta si tienes zsh instalado (apt install zsh)

# Ejemplo de CLI pura: apt tiene una interfaz de línea de comandos
# No necesitas entender bash para entender que esto es CLI
apt --version

Fíjate en la diferencia entre $SHELL y $0. La variable $SHELL contiene la shell que el sistema tiene registrada para tu usuario en /etc/passwd —la que arranca cuando abres una terminal nueva—. La variable $0 refleja la shell que está ejecutando este script o sesión en este momento. Si un administrador lanzó un script con dash pero tu shell por defecto es bash, esas dos variables van a mostrar valores distintos. Esa diferencia tiene consecuencias reales: dash no entiende ciertas sintaxis de bash como los arrays o [[ ]].

El comando grep "^$(whoami):" /etc/passwd te muestra la línea completa de tu usuario en la base de datos de usuarios locales. El último campo de esa línea, separado por :, es la shell que el sistema asignará cuando inicies sesión. En un servidor Debian recién instalado, eso suele ser /bin/bash. Si ves /bin/sh, estás mirando dash en Debian —un ejecutable mucho más ligero pero con menos funcionalidades interactivas—.

El hecho de que puedas ejecutar zsh dentro de una sesión bash —como muestra el comentario— demuestra que la shell es simplemente un proceso hijo más. La terminal no sabe ni le importa qué shell está corriendo dentro; solo muestra caracteres. Y la CLI de apt funciona igual de bien invocada desde bash, desde zsh, o desde un script sin shell interactiva. Cada capa hace su trabajo de forma independiente.

[Ubuntu]: Para abrir una terminal en Ubuntu Desktop, el atajo es Ctrl+Alt+T. En Debian con GNOME, ese atajo no siempre está activado por defecto; búscala en el menú de aplicaciones como “Terminal” o instala y configura el atajo manualmente desde Configuración → Teclado.

6

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll al inicio