Análisis de la línea de comandos en Linux (y algo de Windows)

En el mundo GNU/Linux, una de las herramientas más poderosas que se pueden encontrar es la línea de comandos, a la cual se accede desde la terminal. Muchos programas también utilizan la terminal como interfaz principal, y por eso es necesario conocerlos si queremos aprovechar al máximo el potencial que reside en ellos.

A pesar de todas las herramientas gráficas que se utilizan hoy en día, los sistemas operativos siguen siendo interfaces para controlar el equipo y los programas que usamos. Detrás de cada ventana hay montones de mensajes que se pasan entre el sistema operativo, el programa que muestra la ventana y los dispositivos (pantalla, ratón, teclado...) para llevar a cabo las tareas que necesitamos que realice el equipo. Algunas veces esos mensajes se pasan en forma de comandos que muchas veces podemos imitar usando el teclado, y sin usar interfaces gráficas. ¿Qué ventajas tiene esta posibilidad, si ya existen las herramientas gráficas? Para un usuario común y silvestre puede que ninguna, pero vean cómo nos consultan a los usuarios avanzados cómo hacemos lo que hacemos con los comandos. Para nosotros los comandos representan automatización, precisión, puntualidad, agilidad, y a veces son la única manera de realizar tareas de reparación cuando la interfaz gráfica no está disponible. Es la posibilidad de controlar lo que queremos sin pasar por complicadas ventanas o asistentes, sin buscar el botón correcto o meter los valores en campos de texto, y sin cambiar las manos del ratón al teclado y de vuelta al ratón a cada momento.

Entonces, ¿cómo se usa la terminal? La podemos encontrar en el menú de aplicaciones de nuestro escritorio favorito, o desde una línea de Ejecutar (Alt+F2 en Gnome, Ctrl+Alt+Espacio en IceWM) podemos escribir xterm, gnome-terminal, kterm, konsole, terminator, o cualquiera que nos parezca adecuada. Yo uso xterm, pero en Ubuntu 10 y superiores hay un bug con las fuentes, así que recomiendo gnome-terminal en esos casos. De ahí en adelante lo que haremos es escribir comandos en esa ventana.

Lo primero que notamos es que la ventana muestra nuestro nombre de usuario, una @, y el nombre del equipo, un :~ y el símbolo de $. Esto es, que estamos en el directorio ~ y que somos un usuario no administrativo. El directorio ~ es por lo general /home/miusuario y se representa así cuando se está dentro de él. Además, si estamos como el usuario root nos mostraría un # en lugar de $. Listo, con esto ya pueden saber cuándo en un sitio nos dicen si debemos ejecutar el comando como root o como usuario.

¿Qué son los comandos?

Los comandos son por lo general nombres de archivos ejecutables que hay en algunos directorios que el intérprete de comandos utiliza como referencia. El directorio más común es /usr/bin, en el que se encuentran la mayoría de los programas de usuario, pero puede haber muchos más. Para ver cuáles son debemos escribir ésto:
$ echo $PATH
Nótese que al principio he puesto un $ para indicar que el comando se ejecuta como usuario. También hay un $ antes de PATH, y es para indicar que se trata de una variable en el entorno. El intérprete de comandos (Bash) identifica las variables con ese símbolo. Sin él, se imprimiría la cadena literal "PATH" (sin comillas), en lugar de la lista de directorios que imprime el comando que les di.

Otro dato a tener en cuenta es que el nombre del comando debe ser la primera palabra en la línea de comandos, aunque no necesariamente el primer caracter ya que pueden dejar espacios al principio. Tampoco es necesario quitar los espacios al final de la línea. Además, si uno se equivoca, puede utilizar las flechas del teclado para moverse hacia atrás y cambiar lo que sea necesario. Una vez que se escribe el comando se presiona la tecla Enter, así el cursor no esté al final. La línea es interpretada por el intérprete de comandos y se ejecuta el programa correspondiente.

¿Qué son los parámetros?

Muchos programas reciben sus parámetros desde la línea de comandos. Estos parámetros pueden ser los tiempos que deben esperar algún evento, los archivos con los que deben trabajar, los puertos en los que deben escuchar, la cantidad de líneas que deben imprimir, etc. Un solo programa puede recibir cientos de parámetros de esta manera, y para los usuarios sería muy incómodo aprendernos el orden en que se le deben suministrar (Hey, ese número que escribió es de página, de saltos, de líneas, de caracteres o de bytes?). Por esta razón se utilizan las opciones, y casi todos los desarrolladores intentan ponerse de acuerdo con algún estándar. Las opciones por lo general son del tipo -p (menos pe), -y (menos ye), --ejemplo (menos menos ejemplo) y son dictadas de esa forma. Es decir, se utiliza una sola letra para opciones cortas y palabras mnemotécnicas para opciones largas. Luego de la opción va el valor del parámetro. Veamos algunos ejemplos:

$ ls -l /home
$ mplayer -ao dummy -vo mga video.mpg
$ cdrecord -tao -v dev=0,4,0 speed=10 -eject imagen.iso

Como se observa, algunos programas tienen algunos formatos exóticos para recibir sus opciones, pero también pueden aceptar la forma estándar.

Múltiples comandos, una sola línea

Muchas veces es necesario ejecutar varias tareas en una tanda. Esto es, que podríamos poner a reproducir un archivo y al mismo tiempo descargar otro, o filtrar un archivo de registro buscando sólo las referencias a un evento particular, o programar varias tareas secuenciales, una tras otra. Estos son usos avanzados de la línea de comandos y permiten agrupar varias tareas en una sola línea. La ventaja de hacer esto es que uno puede escribir la línea una vez y aprovechar el tiempo en otras actividades mientras los comandos se ejecutan. Por ejemplo:
# apt-get update && apt-get install partimage ssh firefox gpm kde-desktop && echo $? > salida_apt && beep
En este ejemplo he puesto a actualizar las listas de paquetes que puedo instalar, y luego a que se instalen algunos paquetes que a veces utilizo. Luego el programa guarda el código de salida de la instalación en un archivo de texto plano, y que haga un sonido cuando termine. De esta forma el sistema ejecuta las tareas mientras yo estudio manuales o navego por Internet. Podría sustituir el sonido de beep por, digamos, la reproducción de un sonido del sistema (aplay /usr/share/sounds/kde-start.ogg) o cualquier otra cosa. Aquí la clave está en el uso de conectores de comandos.

El primer conector que usaremos es &&. Sirve para indicar que la parte derecha se hará si y sólo si la parte de la izquierda no tuvo errores. En el caso del ejemplo, no tendría sentido intentar instalar los paquetes nuevos si no se actualizaron las listas que indican qué actualizaciones hay disponibles.

El segundo conector es ||, que significa que el comando de la derecha se ejecuta sólo si el primero falló. Esto es para casos de fallback (de reserva), como si no se puede reproducir un archivo determinado se puede intentar otra forma de llamar la atención.

El tercer conector es ; (Sí, un punto y coma). Esté indica que los comandos se deben ejecutar uno detrás de otro, de manera secuencial y sin importar si uno u otro falla.

El último conecto estándar que les traigo es &, que permite lanzar los comandos en paralelo. Por ejemplo:
$ mplayer /home/usu1/musica/arch1.wav & mplayer /tmp/entrevista.mp3 & mplayer -loop 0 /home/usu2/videofondo12.avi
Esta es una forma bastante curiosa de hacer una presentación de una entrevista, con un fondo animado que se repite (videoloops)

Un comentario para finalizar. Muchos ya conocerán el caracter | (pipe, "paip") con el que se concatenan algunos comandos. Realmente lo que hace es conectarlos de modo que lo que el primero imprima en pantalla sea lo que el otro reciba como si fuera el teclado, pero eso lo dejaré para otra entrega de este interesante tema.