The Inside Out

Uso intermedio de Bash

Vamos a hablar ahora de otros comandos, operaciones y conceptos que no son tan comunes para un usuario nuevo, pero sí muy útiles una vez que se aprenden.

Administración de procesos

Hemos hablado un poco de esto al mencionar los programas top, fs y kill. Sin embargo, hay bastante más (siempre hay más) que decir sobre el tema, y a veces este conocimiento le será muy útil. En particular, veremos conceptos como procesos corriendo en segundo plano,sucesión de comandos, identificadores de procesos, y prioridades. Veremos algo también sobre el uso de variables en comandos. Puede querer asociar lo aprendido aquí con la redirección de salida de comandos que vimos al hablar de less y cat. Aquí terminaremos de ver el concepto. Por último, hablaremos de las prácticas tuberías, y del uso de la memoria en Linux

bg y fg: "minimizar" en consola

Dado que Linux es un kernel con capacidades de multitarea, el shell incorpora comandos para hacer que los programas pasen al frente o al fondo, es decir, son el equivalente en el shell de las acciones "minimizar" y "restaurar". bg envía un trabajo o proceso (un programa que está corriendo) atrás, y fg lo vuelve a traer. Si ha lanzado un comando en una consola puede pulsar Control + Z para pausar el proceso y bg para enviarlo al fondo. Ejemplo:

[rogelio@Edhellond docs]$ gnomeicu
(presionamos Control + Z)
[1]+  Stopped                 gnomeicu
[rogelio@Edhellond docs]$ bg
[1]+ gnomeicu &
[rogelio@Edhellond docs]$ fg
gnomeicu

Luego de ejecutar gnomeicu, pulsamos Control + Z. El trabajo se detuvo, y lo hicimos rearrancar en segundo plano con la orden bg. Note que el mismo resultado puede obtenerse ejecutando directamente gnomeicu &. El símbolo & aplicado al final de un comando hace que se ejecute en segundo plano. Por supuesto, eso no se limita a un solo programa: puede iniciar en segundo plano todos los programas que necesite. Ejecute el comando jobs para verlos a todos:

[rogelio@Edhellond rogelio]$ jobs
[1]-  Running                 gnomeicu &
[2]+  Running                 aterm &

Tenemos dos procesos corriendo ahora en segundo plano. Note el número a la izquierda: fg permite traer al primer plano selectivamente un proceso (por defecto el último) usando ese número. Por ejemplo:

[rogelio@Edhellond rogelio]$ fg
aterm
[rogelio@Edhellond rogelio]$ fg 1
gnomeicu

Colas de comandos

Cuando está trabajando, puede alguna vez querer ejecutar un montón de comandos y dedicar su atención de nuevo a otra cosa (digamos centericq, por ejemplo). El tipo de orden que de depende de una cosa: la relación entre los comandos. Si el resultado de un comando no influye en el comando siguiente, basta usar el símbolo ; para separar comandos en una línea. Si en cambio usted está haciendo una tarea (como compilar el núcleo) que necesita que cada uno de los comandos tenga éxito antes de empezar el siguiente, usará el símbolo &&.

Por ejemplo:

[rogelio@Edhellond rogelio]$ cd docs/foo/ ; ls ~
borrados.log  docs/  tmp/  xcdroast/
[rogelio@Edhellond foo]$

Nos lleva al directorio ~/docs/foo (como se ve por el prompt) y además muestra los archivos del directorio personal. Pero note esto:

[rogelio@Edhellond foo]$ cd docs/foo/bar/ ; ls ~
-bash: cd: docs/foo/bar/: No such file or directory
borrados.log  docs/  tmp/  xcdroast/
[rogelio@Edhellond foo]$

Aquí, aunque la primera orden tiene un error (no existe el directorio bar dentro de foo) la segunda orden sigue cumpliéndose.

Una última nota antes de seguir: cuando vea scripting en otros lenguajes, como perl, python o PHP, notará que el punto y coma se usa para separar comandos de la misma manera.

Ahora veamos el segundo modo con un ejemplo: compilar un programa es una tarea que implica una serie de pasos, y cada uno de ellos debe completarse sin errores para pasar al siguiente, y por eso usamos &&: sólo se pasa a la segunda etapa si la primera terminó correctamente:

[root@Edhellond foo]# ./configure && make && make install

compilará correctamente el programa, o se detendrá al primer error. Note que estamos logueados como el usuario root para poder ejecutar make install normalmente.

PIDs

Ha llegado el momento de hablar un poco más sobre los procesos y su creación. Como ya habrá notado, llamamos proceso a cualquier programa corriendo. En Unix, un proceso se inicia y puede dar nacimiento a otros, que son sus hijos, mediante lo que se conoce como forking o ramificación. Si conoce de biología, el forking es similar a la división celular: allí donde había un proceso hay una división, y quedan dos. Para ordenar esto y poder llamar a cada uno de los programas que corren, el sistema usa la tabla de procesos, en la que cada proceso lleva un número único, dado por el orden de aparición. El primer proceso es init, y de él se desprenden todos los otros al arrancar el sistema. Podríamos tener entonces algo como esto:

[root@Edhellond foo]# pstree
init-+-bbpager
     |-bdflush
     |-login---bash---startx---xinit-+-X
     |                               `-blackbox---xscreensaver

La lista será más larga, pero aquí podemos ver los conceptos de los que hablábamos: pstree (árbol de procesos) muestra todos los procesos principales en árbol. Cuando un proceso se ramifica se muestra un símbolo +, y todos los procesos forkeados aparecen a igual altura. Además, un proceso hijo se muestra como una rama de su padre. En el ejemplo, bash es hijo de login, y startx es hijo de bash.

Ya que hemos hablado de padres e hijos, hablemos de herencia. Como verá en el tutorial sobre usuarios y permisos, cada archivo (y también cada programa) tienen permisos de usuario. Ahora bien, cuando un proceso "nace" hereda algunos de los privilegios o permisos de su padre, a menos que (aquí empieza la diferencia con la vida real) tenga otros propios. Un servidor web o un programa no corren con privilegios de root sólo porque init sí lo hace. Esto depende en parte de que antes de usarlos hay que conectarse usando login, y en parte de que algunos procesos tienen definida su propia cuenta de usuario.

Pero basta de teoría, y sigamos viendo cómo administrar procesos. Ya vimos dos o tres programas importantes: top, ps y kill. Ahora seguiremos con nice y renice.

nice y renice

Estos programas permiten algo importante: cambiar la prioridad de un proceso. En Linux, los procesos corren con un número de importancia entre 19 (la menor) y -20 (la más alta). Los procesos con mayor prioridad tienen preferencia de procesamiento.

¿De qué puede servir esto? Bueno, suponga que quiere grabar un CD y seguir trabajando (suponga también que la PC puede hacer el trabajo). Podría iniciar el comando cdrecord con una prioridad alta, y despreocuparse. Para esto tendrá que conectarse como root, eso sí: un usuario común no puede elevar la prioridad a números negativos (recuerde que la máxima prioridad es -20):

[rogelio@Edhellond foo]$ nice -n 8 aterm &
[2] 5782
[1]   Done                    nice -n 8 aterm
[rogelio@Edhellond foo]$ nice -n -10 aterm &
[3] 5814
nice: no se puede establecer la prioridad: Permission denied
[3]+  Exit 1                  nice -n -10 aterm
[rogelio@Edhellond foo]$

Como ve, el uso de nice es simple: la opción -n número le permite cambiar el número de prioridad. Para cambiar la prioridad de un proceso que ya está corriendo, deberá usar el comando renice, con las mismas limitaciones que nice: un usuario común no puede elevar demasiado la prioridad de un proceso. Deberá conocer el PID del proceso que quiere modificar, y aprovecharemos esto para introducir el siguiente concepto a tratar: variables de shell:

[rogelio@Edhellond foo]$ nice -n 3 gvim &
[1] 6630
[rogelio@Edhellond foo]$ renice 4 $(/sbin/pidof gvim)
6631: prioridad antigua 3, nueva prioridad 4
[1]+  Done                    nice -n 3 gvim

A ver qué hicimos aquí. Primero iniciamos el editor de texto gvim con una prioridad de 3 y en segundo plano. Posteriormente le cambiamos la prioridad a cuatro, usando renice. Esta es la explicación simple, y deja varias cosas por comentar, que veremos inmediatamente. Pero antes, una aclaración: el comando renice sólo funcionará para procesos que el usuario pueda alterar (es decir, que él haya iniciado) y sólo para incrementar prioridades (es decir, para "quitarle importancia" al proceso. Conectándonos como root podremos además aplicar prioridades negativas, y cambiar el factor nice de usuarios (con la opción -u): todos los procesos de esos usuarios correrán por defecto con ese valor de nice.

Variables de shell

En el comando renice que vimos arriba, y que reproducimos aquí, hicimos un truco que le puede resultar desconocido. Veamos de qué hablamos:

rogelio@Edhellond foo]$ renice 4 $(/sbin/pidof gvim)

¿Qué significa exactamente eso de usar paréntesis, y el signo pesos? Lo que estamos haciendo es lo siguiente: creamos y usamos una variable. Al encerrar entre paréntesis y anteponer $ lo que estamos haciendo es decir "Usar el resultado de este comando (en este caso, un PID) como argumento del comando renice". El resultado del comando pidof es el PID del proceso. El valor de la variable entonces es el PID del proceso gvim. Lo que hicimos equivale a esto:

[rogelio@Edhellond foo]$ nice -n 3 gvim &
[1] 6850
[rogelio@Edhellond foo]$ ps x
  PID TTY      STAT   TIME COMMAND
 2314 pts/0    S      0:00 -bash
 6851 ?        SN     0:00 gvim
 6852 pts/0    R      0:00 ps x
[1]+  Done                    nice -n 3 gvim
[rogelio@Edhellond foo]$ renice +4 6851
6851: prioridad antigua 3, nueva prioridad 4

Es decir, buscar el proceso creado y copiar su PID al usar renice. Este ejemplo más o menos simple (este tutorial no lleva "intermedio" en su nombre por nada) nos muestra cómo aplicar variables para hacer comandos más cortos. Sigamos ahora con el otro concepto importante (algunos dirían, el más importante): la comunicacion inter-procesos, o IPC (inter-process communication) y el uso de tuberías.

Uso de pipes o tuberías

¿Recuerda el principio de estos tutoriales, donde dijimos que una de las virtudes de Unix es la modularidad? Bueno, lo que conecta entre sí todos estos pequeños programas o módulos son los pipes o tuberías. Se usa el símbolo | (en un teclado con mapeado español se obtiene con Alt Gr + 1) para representar un pipe entre un proceso y otro. Los pipes permiten que la información que da un comando esté disponible directamente para otro comando. ¿Ejemplos? Veamos:

[rogelio@Edhellond foo]$ rpm -qa | grep gnomeicu
gnomeicu-0.98.126-2mdk

Como ve, usamos el resultado del comando rpm -qa (mostrar la lista de todos los paquetes rpm) como entrada para el comando grep gnomeicu Resultado: buscamos dentro de la lista de todos los paquetes los que contuvieran la frase "gnomeicu". Otro ejemplo:

[root@Edhellond foo]# cat /var/log/messages | less

Le mostrará el contenido del archivo de log messages (deberá conectarse como root). No hay límite a la cantidad de pipes que pueda usar. Ultimo ejemplo:

tar -cvf docs.tar docs/ | gzip -v docs.tar
docs.tar: 65.2% -- replaced with docs.tar.gz

Esto crea un archivo agrupado con el comando tar, y luego gzipea (comprime) ese archivo.

Uso de la memoria RAM

Este tema, aunque no lo crea, también se relaciona con los procesos. Además, es una de las mayores diferencias con otros sistemas operativos.

Apenas use el comando free usted verá algo como esto:

[rogelio@Edhellond rogelio]$ free
             total       used       free     shared    buffers     cached
Mem:        251960     246884       5076          0      16136     110072
-/+ buffers/cache:     120676     131284
Swap:       393552       3612     389940
[rogelio@Edhellond rogelio]$ 

Interpretemos esto: el comando nos devuelve información ordenada a partir del archivo /proc/meminfo. La primera línea de free muestra datos de la RAM instalada en el sistema, empezando por la total (256 MB, de los cuales más o menos 5 se usan para ocultar el kernel y algunas otras cosas); con aparentemente 246 MB usados, y sólo unos 5 MB libres. Esto es lo que a muchos usuarios nuevos (a nosotros incluídos) les hizo alguna vez sorprenderse. Ahora, sigamos leyendo hasta el final: hay aproximadamente 110 MB de memoria cacheada, es decir, con datos almacenados por si acaso. Esa cantidad de memoria en realidad está disponible si algún proceso la usa, pero si no, almacena librerías compartidas o accesos a directorios, lo que acelera su carga.

Es por esta razón que no hay que apagar de manera "incorrecta" la PC: gran parte del sistema de archivos puede estar abierto y cargado en la RAM, por lo que un Reset "duro" puede provocar la pérdida de datos. Esto se hace cada vez más difícil a medida que los sistemas de archivos de Linux mejoran, pero lo mejor siempre será tomarse la molestia de apagar con el comando halt -p o desde el modo gráfico.

Con esto hemos atravesado por un montón de conceptos importantes para el uso completo del sistema. Tome un descanso, practique con lo que ya sabe, y consulte la ayuda para saber más sobre otros comandos. Cuando esté listo o lo necesite, pase al tercer tutorial, en el que hablaremos sobre búsqueda de archivos.