Anatomía de un comando

1. Un idioma con gramática

En el tema 1 dijimos que la línea de comandos se parece a un idioma. La comparación es más exacta de lo que parece. Una orden como «copia este archivo a aquella carpeta, conservando las fechas» tiene un verbo, unos objetos y un modo. Un comando tiene las mismas tres cosas, siempre en el mismo orden:

comando  [opciones]  [argumentos]
   │          │            │
   │          │            └─ sobre qué: archivos, directorios, textos
   │          └─ cómo: modificadores del comportamiento
   └─ qué hacer: el nombre de un programa

Los corchetes indican que una parte es opcional: hay comandos que se usan solos, y otros que no hacen nada sin argumentos. Aprender esta estructura rinde mucho más que memorizar comandos. Quien la conoce puede leer una línea desconocida y saber, al menos, qué papel cumple cada palabra; y puede adivinar con bastante acierto cómo se usa un comando nuevo.

Para los ejemplos de este tema usaremos el directorio de práctica del tema 2, con dos elementos más:

$ cd ~/practica
$ mkdir fotos                       # un directorio vacío
$ cp /etc/services informe.txt      # una copia de un archivo de texto del sistema
$ ls
fotos  informe.txt  notas.txt

2. Las tres partes

Veamos un comando completo, con sus tres partes a la vista:

ls -l --human-readable fotos notas.txt
│  │  │                └─ argumentos: sobre qué actúa
│  │  └─ opción larga: dos guiones y una palabra
│  └─ opción corta: un guion y una letra
└─ nombre: qué programa se ejecuta

El mismo comando, ls, se comporta de maneras distintas según lo que se le añada:

$ ls                                # solo el nombre
fotos  informe.txt  notas.txt

$ ls -l                             # con una opción: formato largo
total 24
drwxrwxr-x 2 ana ana  4096 oct 12 10:40 fotos
-rw-rw-r-- 1 ana ana 12813 oct 12 10:41 informe.txt
-rw-rw-r-- 1 ana ana    18 oct 12 10:32 notas.txt

$ ls notas.txt                      # con un argumento: solo ese archivo
notas.txt

$ ls -l notas.txt                   # opción y argumento
-rw-rw-r-- 1 ana ana    18 oct 12 10:32 notas.txt

Sin nada, ls lista los nombres del directorio actual. La opción -l le pide más detalle, sin cambiar qué lista. El argumento notas.txt cambia sobre qué actúa, sin cambiar cómo lo muestra. Son dos ejes independientes, y se combinan. Los tamaños y las fechas serán otros en tu equipo; lo que significa cada columna lo vemos en el tema 7.

3. Los espacios separan

La shell divide la línea en palabras usando los espacios. Es una regla sencilla, con dos consecuencias que conviene tener claras desde el primer día.

La primera es que la cantidad de espacios no importa, pero su presencia sí:

$ ls    -l      notas.txt            # varios espacios: es lo mismo que uno
-rw-rw-r-- 1 ana ana 18 oct 12 10:32 notas.txt
$ ls-l                              # ningún espacio: es otra palabra
ls-l: command not found
$ ls - l                            # un espacio de más: son dos argumentos
ls: cannot access '-': No such file or directory
ls: cannot access 'l': No such file or directory

En el segundo caso, la shell buscó un programa llamado ls-l, que no existe. En el tercero, ls recibió dos palabras sueltas, un guion y una ele, y las tomó como nombres de archivo. La mayor parte de los errores de quien empieza son de esta clase: un espacio que falta o que sobra.

La segunda consecuencia es que un espacio dentro de un nombre lo parte en dos. Un archivo llamado mis notas.txt es, para la shell, dos palabras. Para que lo trate como una sola hay que encerrarlo entre comillas:

$ echo uno      dos                 # dos argumentos: echo los une con un espacio
uno dos
$ echo "uno      dos"               # un solo argumento: los espacios se conservan
uno      dos

El ejemplo deja ver quién hace qué. En la primera línea, echo nunca supo cuántos espacios habías escrito: la shell los descartó al separar las palabras, y le entregó dos argumentos. Las comillas le dicen a la shell «esto es una sola palabra». Les dedicamos el tema 9; por ahora, la recomendación práctica es no usar espacios en los nombres de archivo, y reemplazarlos por guiones.

4. Opciones cortas

La forma tradicional de una opción es un guion seguido de una sola letra. Son rápidas de escribir, y tienen tres propiedades que se aprovechan a diario:

$ ls -l -h                          # dos opciones
total 24K
drwxrwxr-x 2 ana ana 4,0K oct 12 10:40 fotos
-rw-rw-r-- 1 ana ana  13K oct 12 10:41 informe.txt
-rw-rw-r-- 1 ana ana   18 oct 12 10:32 notas.txt

$ ls -lh                            # lo mismo, agrupadas tras un solo guion
$ ls -hl                            # lo mismo: el orden no importa

$ head -n 2 informe.txt             # una opción que lleva un valor
# Network services, Internet style
#

La opción -h hace que los tamaños se muestren en unidades legibles, como K o M, en lugar de bytes. head -n 2 muestra las dos primeras líneas de un archivo: el 2 no es un argumento del comando, sino el valor de la opción -n.

Hay una dificultad que no conviene ocultar: la misma letra significa cosas distintas en comandos distintos. Cada programa define sus opciones. -n indica una cantidad de líneas en head, pide numerar las líneas en cat, y hace que echo no añada el salto de línea final. No hay más remedio que consultar la ayuda de cada comando, que es el asunto del tema 4. Existen, eso sí, algunas costumbres muy extendidas:

Son costumbres, no garantías. Sirven para orientarse, y siempre hay que verificarlas.

5. Opciones largas

Las letras se acaban pronto, y no dicen mucho. Por eso el proyecto GNU, del que provienen casi todas las utilidades de Linux, añadió una segunda forma: dos guiones seguidos de una palabra completa.

$ ls --all                          # igual que ls -a
.  ..  fotos  informe.txt  notas.txt
$ ls -l --human-readable            # igual que ls -lh; se pueden mezclar las dos formas
$ head --lines=2 informe.txt        # igual que head -n 2
# Network services, Internet style
#

La mayoría de las opciones tiene las dos formas, y son equivalentes. La elección es de comodidad: al teclear en la terminal se usan las cortas; al guardar un comando en un archivo que otra persona leerá dentro de un año, las largas ahorran una consulta al manual. Ahora se entiende, además, por qué las largas llevan dos guiones: con uno solo, -all se confundiría con las tres opciones cortas -a, -l y -l.

Hay dos opciones largas que existen en casi todos los comandos, y son las primeras que conviene probar ante uno desconocido:

$ ls --version                      # qué versión del programa es
ls (GNU coreutils) 9.4
…
$ ls --help                         # un resumen de su uso y de todas sus opciones
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
…

6. Argumentos

Los argumentos son el material con que trabaja el comando: casi siempre nombres de archivos o de directorios, a veces un texto o un número. Cuántos admite, y qué significa cada uno, lo decide el comando.

La última fila es la que exige atención. En cp notas.txt copia.txt, invertir los argumentos copia en el sentido contrario, y sobrescribe el archivo que querías conservar. Ante un comando con dos argumentos de papeles distintos, la convención casi universal es origen primero, destino después.

La segunda fila esconde una trampa en la que cae todo el mundo. Varios comandos que trabajan con archivos, cuando no reciben ninguno, leen del teclado:

$ cat notas.txt                     # con argumento: muestra el archivo
Mi primer archivo
$ cat                               # sin argumento: queda esperando…
hola                                # …lo que escribas…
hola                                # …y lo repite
^D                                  # Ctrl+D indica que no hay más, y el comando termina
$ 

El comando no se colgó: está haciendo lo que se le pidió, con el teclado como archivo. Si ejecutas un comando y el indicador no vuelve, y no hay ningún mensaje, lo más probable es que esté esperando que escribas. Ctrl+D le indica que la entrada terminó; Ctrl+C lo interrumpe sin más. La razón de este comportamiento, que parece un defecto y es una virtud, la veremos en el tema 22.

7. El doble guion

Si todo lo que empieza con guion es una opción, ¿cómo se le pasa a un comando un argumento que empieza con guion? No es un caso de laboratorio: basta con un archivo cuyo nombre empiece así. Para eso existe una convención: dos guiones solos, que significan «aquí terminan las opciones».

$ touch -- -prueba                  # crear un archivo llamado «-prueba»
$ ls -l -prueba
ls: invalid option -- 'e'
Try 'ls --help' for more information.

$ ls -l -- -prueba                  # lo que sigue a -- son argumentos, empiecen como empiecen
-rw-rw-r-- 1 ana ana 0 oct 12 11:05 -prueba

$ rm -- -prueba                     # borrarlo

En el segundo comando, ls interpretó -prueba como un grupo de opciones cortas: -p, -r, -u, y al llegar a -e, que no existe, se detuvo. Con el doble guion, todo lo que viene después se trata como argumento. Otra solución, que no requiere recordar nada, es escribir el nombre con una ruta delante: ./-prueba ya no empieza con guion.

Esto tiene un lado serio. Un archivo llamado -rf, creado por descuido o con mala intención, se convertiría en una opción al usar un comodín con un comando de borrado. Por eso los scripts cuidadosos ponen siempre -- antes de los nombres de archivo que no controlan.

Hay una convención relacionada: un guion solo, -, usado como argumento, significa en muchos comandos «la entrada estándar» en lugar de un archivo. Lo encontraremos al llegar a las tuberías.

8. Los que no siguen las reglas

La gramática de las secciones anteriores es una convención, no una ley. La shell se limita a separar las palabras y entregárselas al programa; interpretarlas es asunto de cada programa. La gran mayoría respeta la convención, y unos pocos, por razones históricas, tienen la suya. Conviene reconocerlos para no desconcertarse:

Hay además una familia de comandos modernos organizados en subcomandos. Son programas que hacen muchas cosas distintas, y la primera palabra después del nombre elige cuál:

apt install nano
│   │       └─ argumento del subcomando
│   └─ subcomando: qué operación realizar
└─ comando

git commit -m "Primer cambio"
systemctl status cron
ip address show

En estos comandos, cada subcomando tiene sus propias opciones, y suele tener su propia ayuda: apt install --help, git commit --help. Los encontraremos en el bloque 8.

9. Leer una sinopsis

La línea Usage: que mostró ls --help es una sinopsis: un resumen, en una notación compacta, de cómo se arma el comando. Aparece en todas las ayudas y en todas las páginas del manual, y usa siempre los mismos signos:

Los corchetes y los puntos suspensivos son parte de la notación: no se escriben. Con esa clave se leen las sinopsis de los comandos que ya usamos:

Las dos últimas filas muestran que un comando puede tener varias sinopsis, una por cada manera de usarlo. Saber leerlas convierte una ayuda de diez pantallas en algo que se consulta en segundos.

10. Cinco clases de comandos

Hasta aquí dijimos que la primera palabra es «el nombre de un programa». Es cierto casi siempre, pero no siempre. Cuando la shell recibe una línea, busca la primera palabra en cinco lugares, en este orden, y usa lo primero que encuentra:

Las clases 2 y 3 pertenecen a la programación en Bash, que es el contenido del curso siguiente. Los alias los vemos en el tema 5. Las dos últimas son las que importan ahora. Para saber a qué clase pertenece un comando existe type:

$ type cd
cd is a shell builtin
$ type cp
cp is /usr/bin/cp
$ type ls
ls is aliased to `ls --color=auto'
$ type if
if is a shell keyword

La tercera respuesta tiene su gracia. El ls que venimos usando no es directamente el programa: en Ubuntu es un alias que le añade una opción para mostrar colores. Cuando escribes ls, la shell lo reemplaza por ls --color=auto, y recién entonces busca el programa. El orden de la tabla es lo que hace posible ese truco: como los alias se consultan primero, uno puede «tapar» a un programa del mismo nombre.

11. Comandos internos

Un comando interno (builtin) es una operación que la shell ejecuta por sí misma, sin poner en marcha ningún otro programa. Forma parte del código de la propia shell.

Hay dos motivos para que un comando sea interno:

El primer motivo se entiende con cd. Cada programa en ejecución tiene su propio directorio actual. Si cd fuera un programa, al ejecutarlo cambiaría su directorio, terminaría enseguida, y la shell seguiría donde estaba. Solo la shell puede cambiar el directorio de la shell.

Los comandos internos tienen su propia ayuda, con el comando help, también interno:

$ help cd
cd: cd [-L|[-P [-e]] [-@]] [dir]
    Change the shell working directory.
…
$ type -a echo                      # todas las formas de «echo» que existen
echo is a shell builtin
echo is /usr/bin/echo
echo is /bin/echo

La opción -a de type muestra todas las coincidencias, no solo la primera. echo existe dos veces: como comando interno y como programa. Se usa el interno, porque está antes en el orden de búsqueda. El programa queda para las situaciones en que no hay una shell de por medio.

Esto explica una diferencia que sorprende al cambiar de shell. Los comandos externos son los mismos en todas. Los internos son de cada una: el echo de Bash y el de otra shell pueden diferir en algún detalle.

12. Comandos externos y la variable PATH

Un comando externo es un archivo ejecutable guardado en el disco. Para ejecutarlo, la shell debe localizarlo y pedir al sistema operativo que lo ponga en marcha.

La pregunta es dónde lo busca. Recorrer el disco entero en cada comando sería lentísimo. La shell busca solo en una lista de directorios, que está guardada en una variable llamada PATH:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$ ls -l /usr/bin/cp
-rwxr-xr-x 1 root root 141848 abr  5  2024 /usr/bin/cp
$ ls /usr/bin | wc -l               # cuántos programas hay en ese directorio
1184

El valor de PATH es una serie de directorios separados por dos puntos. Cuando escribes cp, la shell mira en el primero si hay un archivo ejecutable con ese nombre; si no, en el segundo; y así hasta encontrarlo. En este equipo aparece en el cuarto, /usr/bin, que es donde vive la mayoría de los comandos. Si recorre toda la lista sin éxito, responde command not found.

De este mecanismo se siguen varias cosas que de otro modo parecen caprichosas:

• Un comando es un archivo. cp es /usr/bin/cp, con su tamaño, su dueño y sus permisos. Instalar un programa es, en esencia, copiar un archivo a uno de esos directorios.
• El orden de la lista importa. Si hay dos programas con el mismo nombre en dos directorios, se ejecuta el del que aparece antes.
• Se puede saltar la búsqueda. Escribiendo la ruta completa, /usr/bin/cp, la shell ejecuta ese archivo sin consultar PATH.
• El directorio actual no está en la lista. Un programa que tengas en tu directorio no se ejecuta por su nombre: hay que indicar dónde está, con ./programa.

El último punto es una medida de seguridad. Si la shell buscara en el directorio actual, bastaría que alguien dejara en una carpeta un archivo llamado ls para que, al entrar y listar, ejecutaras su programa en lugar del verdadero. Exigir el ./ obliga a que ejecutar algo del directorio actual sea siempre una decisión explícita.

Cómo se modifica PATH para añadir un directorio propio lo vemos en el tema 34.

13. type, which y compañía

Hay varios comandos para averiguar qué se va a ejecutar al escribir un nombre. Hacen cosas parecidas y no iguales:

$ which cp
/usr/bin/cp
$ which cd                          # no responde nada: cd no es un archivo
$ which ls                          # no sabe que ls es un alias
/usr/bin/ls
$ whereis cp
cp: /usr/bin/cp /usr/share/man/man1/cp.1.gz

La diferencia de fondo es que which es un programa externo. Solo sabe recorrer PATH, y no puede conocer los alias, las funciones ni los comandos internos, que existen únicamente dentro de la shell. type es un comando interno, y ve lo mismo que ve la shell. Cuando la pregunta es «¿qué va a pasar si escribo esto?», la respuesta confiable es la de type.

14. El código de salida

Además de lo que escribe en pantalla, todo comando deja al terminar un número, el código de salida, que indica cómo le fue. No se muestra, pero la shell lo guarda en una variable especial, $?, hasta que se ejecuta el comando siguiente:

$ ls notas.txt
notas.txt
$ echo $?
0
$ ls nada.txt
ls: cannot access 'nada.txt': No such file or directory
$ echo $?
2

La convención es la inversa de la que se esperaría: cero es éxito, y cualquier otro valor, fracaso. Tiene lógica: hay una sola manera de que algo salga bien y muchas de que salga mal, y los números distintos de cero permiten distinguirlas.

Es la versión para programas del silencio del tema 1. Una persona sabe que un comando funcionó porque no dijo nada; un script lo sabe porque el código es cero. En el tema 25 usaremos este número para encadenar comandos, de modo que el segundo se ejecute solo si el primero tuvo éxito.

15. Leer un mensaje de error

Los mensajes de error de los comandos son escuetos, y siguen casi todos el mismo formato. Leído por partes, cada uno dice exactamente qué pasó:

ls: cannot access 'nada.txt': No such file or directory
│   │                         └─ el motivo, informado por el sistema operativo
│   └─ qué intentaba hacer, y con qué
└─ quién informa: el programa que falló

La primera parte es la más útil y la que menos se mira. En una línea con varios comandos encadenados, es la que indica cuál de ellos falló. Si en lugar de un programa aparece bash:, el error es de la shell, que no llegó a ejecutar nada. Estos son los que encontrarás en los primeros días:

En Ubuntu, la primera fila suele venir con una ayuda adicional. Si el nombre corresponde a un programa que existe y no está instalado, el sistema lo dice:

$ tree
Command 'tree' not found, but can be installed with:
sudo apt install tree

La regla general es la del tema 1, y vale la pena repetirla: los mensajes de error se leen. Son breves, están escritos para ser leídos, y nueve veces de cada diez contienen la solución. Cuando no alcanza, el paso siguiente es consultar la ayuda del comando, que es el asunto del tema 4.

16. Resumen

• Un comando tiene tres partes: el nombre, las opciones, que modifican cómo trabaja, y los argumentos, que indican sobre qué.
• La shell separa la línea en palabras por los espacios. Un espacio de más o de menos cambia el significado.
• Las opciones cortas son un guion y una letra; se agrupan, y su orden suele ser libre. Algunas llevan un valor.
• Las opciones largas son dos guiones y una palabra. Equivalen a las cortas y son más legibles. --help y --version existen casi siempre.
• La misma letra puede significar cosas distintas en comandos distintos: cada programa define sus opciones.
• En los comandos con dos argumentos de papeles distintos, el orden es origen y luego destino.
• Muchos comandos, si no reciben un archivo, leen del teclado. Ctrl+D indica el fin de la entrada.
• Dos guiones solos marcan el fin de las opciones, y permiten usar argumentos que empiezan con guion.
• En una sinopsis, los corchetes indican algo opcional, los puntos suspensivos una repetición y las mayúsculas un valor a reemplazar.
• La shell busca cada comando entre los alias, las palabras reservadas, las funciones, los comandos internos y los programas, en ese orden.
• Los comandos internos los ejecuta la propia shell. Los externos son archivos, que la shell busca en los directorios de PATH.
• type indica qué se ejecutará realmente; which solo conoce los archivos.
• Todo comando deja un código de salida en $?: cero si tuvo éxito, otro número si falló.
• Un mensaje de error indica quién falló, qué intentaba y por qué.

17. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. En ~/practica, ejecuta ls, ls -a, ls -l, ls -la y ls -l -a. ¿Cuáles dan el mismo resultado?
2. Prueba ls -lh, ls -hl y ls -l --human-readable. Luego prueba ls -r y ls -R, y describe la diferencia.
3. Muestra las cinco primeras líneas de informe.txt de dos maneras: con la opción corta y con la larga.
4. Ejecuta cat sin argumentos, escribe tres líneas y termina con Ctrl+D. Repite, y termina con Ctrl+C. Mira el código de salida con echo $? en cada caso.
5. Crea con touch -- -raro un archivo cuyo nombre empiece con guion. Lístalo con ls -l y bórralo, usando las dos soluciones de la sección 7.
6. Averigua con type a qué clase pertenecen pwd, mkdir, exit, grep, for y ll.
7. Ejecuta type -a pwd. ¿Cuántas formas de pwd hay, y cuál se usa?
8. Muestra tu PATH. Cuenta cuántos directorios tiene, y averigua con which en cuál están ls, bash y sudo.
9. Ejecuta ls --help y lee la línea Usage. Haz lo mismo con cp, mv y head, y traduce cada sinopsis a una frase.
10. Provoca los primeros seis mensajes de la tabla de la sección 15, y después de cada uno consulta el código de salida.