Bueno, la mayoría de la gente que tiene que ver con los comandos de UNIX expuestos en este capítulo no estarán de acuerdo con este título. "¡Que diablos! Se me ha enseñado que el interfaz del Linux es muy estándar, y ahora tenemos un grupo de comandos, cada uno trabajando de una manera completamente diferente. Nunca recordaré todas esas opciones, ¿y dice que son divertidos?"

Sí, Vd. ha visto un ejemplo del humor de los hackers1. Además, mírelo desde el lado positivo: no hay comandos del MS-DOS equivalentes a éstos. Si los necesita, tiene que adquirirlos por separado, y nunca sabrá como será su interfaz. Aquí hay un útil (y económico) valor añadido, ¡¡así que disfrútelo!!.

El conjunto de comandos explicados en este capítulo cubre find, que permite al usuario buscar grupos de ficheros especificados dentro del árbol de directorios; tar, útil para empaquetar algún archivo para ser enviado o sólo salvado; dd, el multicopista de bajo nivel; y sort, el cual . . . sí, clasifica ficheros. Una última condición: estos comandos no están bajo ningún concepto estandarizados, y si bien podríamos encontrar un núcleo de opciones comunes en todos los sistemas *IX, las versiones (de GNU) que se explican más abajo, y Vd. puede encontrar en su sistema Linux, usualmente poseen muchas más capacidades. Por tanto, si Vd. planea usar otros sistemas operativos UNIX, por favor, no olvide comprobar la página del manual del sistema en cuestión para aprender las quizás no tan pequeñas diferencias.

Entre los diversos comandos vistos hasta aquí, había algunos que permitían al usuario bajar recursivamente el árbol del directorio para llevar a cabo alguna acción: los ejemplos canónicos son "ls -R" y "rm -R" . Bien. find es el comando recursivo. Cada vez que piense "Bueno, tengo que hacer tal cosa con todos esos ficheros en mi propia partición", haría mejor en pensar en usar find. En cierto sentido el hecho que find encuentre ficheros es solo un efecto secundario: su ocupación real es evaluar.

_____________________________________________

1 N.T.: La palabra Hacker en este contexto se refiere a una persona con profundos conocimientos de informática.

La estructura básica del comando es como sigue:

Esto es al menos en la versión de GNU; otras versiones no permiten especificar más que una ruta, y además es muy infrecuente la necesidad de hacer tal cosa. La explicación burda de la sintaxis del comando es bastante simple: Vd. indica desde dónde quiere empezar la búsqueda (la parte de la ruta; con el find de GNU puede omitir esto y será tomado por defecto el directorio en uso .), y que clase de búsqueda quiere realizar (la parte de la expresión).

El comportamiento estándar del comando es un poco engañoso, por lo que más vale tenerlo en cuenta. Supongamos que en su directorio principal de usuario existe un directorio llamado basura, el cual contiene un fichero foobar. Vd. felizmente escribe "find . -name foobar" (lo que como puede adivinar busca ficheros llamados foobar), y obtiene . . . nada más que otra vez el prompt. El problema reside en el hecho de que find es por defecto un comando silencioso; sólo devuelve 0 si la búsqueda fue completada (con o sin haber encontrado algo) o un valor distinto de cero si hubiera habido algún problema. Esto no ocurre con la versión que Vd. puede encontrar en el Linux, pero de todas maneras es útil recordarlo.

La parte de la expresión puede ser dividida en cuatro grupos diferentes de palabras clave: opciones, tests, acciones, y operadores. Cada uno de ellos puede devolver un valor verdadero/falso, junto con un efecto secundario. La diferencia entre los grupos se muestra a continuación.

opciones afecta a la función general de find, más que al procesamiento de un solo fichero. Un ejemplo es "-follow", el cual instruye a find para seguir enlaces simbólicos en vez de sólo presentar el nodo-i. Siempre devuelven verdadero.

tests son verdaderos tests (por ejemplo, "-empty" comprueba si el fichero está vacío), y puede devolver verdadero o falso.

acciones tienen también un efecto secundario sobre el nombre del fichero considerado. Pueden asimismo devolver verdadero o falso.

operadores no devuelven realmente un valor (convencionalmente pueden ser considerados como verdaderos), y se usan para construir expresiones sintéticas. Un ejemplo es "-or" , el cual hace la OR lógica de las dos subexpresiones a su lado. Note que cuando se yuxtaponen expresiones, está involucrada una "-and" .

Debe advertir que find depende del intérprete de comandos para tener la línea de comandos analizada sintácticamente: esto significa que todas las palabras clave deben ser introducidas entre espacios en blanco y además, que hay un montón de caracteres bonitos que deberán precederse de escape, si no serían destrozados por el propio intérprete de comandos. Cada vía de escape (barra invertida, simples y dobles comillas) está bien; en los ejemplos las palabras clave de un solo carácter se señalizarán en general mediante con una barra invertida, porque es la manera más simple (al menos en mi opinión. ¡Y soy yo quien está escribiendo estas notas!).

Aquí está la lista de todas las opciones conocidas de la versión GNU de find. Recuerde que siempre devuelven verdadero.

-daystart mide el tiempo transcurrido no desde hace 24 horas si no desde la última medianoche.

Un auténtico hacker probablemente no entenderá la utilidad de tal opción, pero un trabajador que programa de ocho a cinco si lo apreciará.

-depth procesa el contenido de cada directorio antes que el directorio en si. A decir verdad, no conozco muchos usos de esto, aparte de una emulación del comando "rm -F" (por supuesto Vd. no puede borrar un directorio antes de que todos sus ficheros sean borrados también . . .

-follow respeta (es decir, sigue) los enlaces simbólicos. Implica la opción "-noleaf" ; ver abajo.

-noleaf desactiva una optimización que dice "Un directorio contiene dos subdirectorios menos que su cuenta de enlaces rígidos2". Si el mundo fuera perfecto, todos los directorios serían referenciados por cada uno de sus subdirectorios (a causa de la opción ..), como . dentro de sí mismo, y por su nombre "real" desde su directorio padre.

Esto significa que cada directorio debe ser referenciado al menos dos veces (una por sí mismo, otra por su directorio padre) y cualquier referencia adicional es por subdirectorios. En la práctica, sin embargo, los enlaces simbólicos y los sistemas de fichero distribuidos3 pueden alterar esto. Esta opción hace que find funcione ligeramente más despacio, pero debe dar los resultados esperados.

-maxdepth niveles, -mindepth niveles, donde niveles es un entero no negativo. Indican respectivamente que a lo sumo o que al menos niveles de directorios deberían explorarse. Un par de ejemplos son obligados: "-maxdepth 0" indica que el comando debería realizarse sólo sobre los argumentos de la línea de comandos, es decir, sin bajar recursivamente el árbol de directorios; "-mindepth 1" inhibe el procesamiento del comando para los argumentos en la línea de comandos, pero se consideran todos los otros ficheros debajo.

-version imprime la versión en uso del programa.

-xdev, el cual es un nombre engañoso, instruye a find para no cruzarse de dispositivo4, es decir, no cambiarse de sistema de ficheros. Es muy útil cuando se tiene que buscar algo en el sistema de ficheros raíz; en muchas máquinas es una partición algo pequeña, pero, sino, ¡un "find /" buscaría en la estructura entera! Podemos así evitar los sistemas de archivo que no son promisorios.

_____________________________________________

2 N.T. hard link count

3 Los sistemas de fichero distribuidos permiten a los ficheros mostrarse como si fueran locales a una máquina cuando realmente están situados en algún otro lugar.

4 N.T.: to cross device

Los dos primeros test son muy simples de comprender: "-false" siempre devuelve falso, mientras que "-true" siempre devuelve verdadero. Otros test que no necesitan la especificación de un valor son "-empty" , el cual devuelve verdadero si el fichero está vacío, y el par "-nouser" /"-nogroup" , los cuales devuelven verdadero en el caso que ninguna entrada en /etc/passwd o /etc/group cuadre con el identificador de usuario/grupo del propietario del fichero. Veamos un problema común en los sistemas multiusuario: se borra un usuario, pero los ficheros pertenecientes a él permanecen en la parte más extraña de los sistemas de ficheros, y debido a las leyes de Murphy ocupan mucho espacio.

El par de test que hemos visto en último lugar nos permitirá encontrar esos archivos. Por supuesto, es posible buscar un usuario o grupo específico. Los test son "-uid nn" y "-gid nn" . Desafortunadamente no es posible dar directamente el nombre del usuario, sino que es necesario usar el identificador numérico, nn.

Además está permitido usar las formas "+nn" , que significa "un valor estrictamente más grande que nn", y "-nn" , que significa "un valor estrictamente más pequeño que nn". Esto es bastante estúpido en el caso de identificadores de usuario5, pero se volverá práctico con otros test.

Otra opción útil es "-type c" , la cual devuelve verdadero si el fichero es del tipo especial de carácter. Los mnemónicos para las posibles selecciones son las mismas letras que se encuentran en ls; entonces, tenemos bloque cuando el fichero es uno especial de bloque; directorio; pipes para tuberías designadas6; link para enlaces simbólicos, y socketssockets7. Los ficheros regulares se indican con file.

Un test relacionado es "-xtype", que es similar a "-type" excepto en el caso de enlaces simbólicos.

Si se ha proporcionado la opción "-follow" , se examina el enlace, en lugar del fichero al que se apunta. El test "-fstype type " no tiene nada que ver; en este caso, lo que se examina es el tipo del sistema de ficheros. Creo que la información se consigue del fichero /etc/mtab, el único que presenta los sistemas de ficheros montados; estoy seguro que los tipos nfs, tmp, msdos y ext2 están entre los reconocidos.

Los test "-inum nn " y "-links nn " examinan si el fichero tiene número de nodo-i nn, o nn enlaces, mientras que "-sizenn " es verdadero si el fichero tiene nn bloques de 512 bytes asignados. (Bueno, no precisamente; para ficheros disgregados los bloques no asignados también se cuentan).

Como hoy en día el resultado de "ls -s" no siempre se mide en trozos de 512 bytes (Linux, por ejemplo, usa 1 kbyte como la unidad), es posible adicionar a nn el caracter "b" , el cual significa contar en bytes, o "k" , contar en kilobytes.

Los bits de permiso son examinados a través del test "-perm mode " . Si el modo no está antecedido por un signo, entonces los bits de permiso del fichero deben cuadrar exactamente con ellos.

Un "-" al principio significa que todos los bits de permiso deben ser puestos a uno, pero no hace suposiciones sobre los otros; un "+" al principio se satisface sólo si cualquiera de los bits está a uno.

_____________________________________________

5 N.T.: UIDs

6 N.T.: named pipes

7 N.T.: enchufe

¡Ups! Olvidé decir que el modo se escribe en octal o simbólicamente, como se usa en chmod. El próximo grupo de test está relacionado con el tiempo que hace que se ha utilizado un fichero por última vez. Esto viene bien cuando un usuario ha llenado su espacio, ya que usualmente hay muchos ficheros que no usaba desde hace años, y cuyo significado ha olvidado. El problema es localizarlos, y find es la única esperanza a la vista. "-atime nn " es verdadero si la última vez que se accedió al fichero fue hace nn días; "-ctime nn " si el estado del fichero fue cambiado por última vez hace nn días, por ejemplo, con un chmod, y "-mtime nn " si el fichero fue modificado por última vez hace nn días. Algunas veces Vd. necesita una marca de tiempo 8 más precisa; el test "-newer archivo " se satisface si el fichero considerado ha sido modificado más tarde que el archivo. Por lo tanto, Vd. sólo tiene que usar touch con la fecha deseada, y ya está. El find de GNU añade los test "-anewer" y "-cnewer" los cuales se comportan de una manera similar; y los test "-amin" , "-cmin" y "-mmin" que cuentan el tiempo en minutos en vez de períodos de 24 horas.

Por último pero no menos importante, el test que yo uso más a menudo. "-name patrón" es verdadero si el nombre del fichero concuerda exactamente con patrón, el cual es más o menos el único que se usaría en un ls estándar. (¿Por qué 'más o menos'? Porque, por supuesto, Vd. tiene que recordar que todos los parámetros son procesados por el intérprete de comandos, y esos encantadores metacaracteres sufren una expansión. Así, un test como "-name foo*" no devolverá lo que Vd. desea, y Vd. debería escribir cualquiera de los dos "-name foo" o "-name "foo*"" . Este es probablemente uno de los más comunes errores cometidos por usuarios descuidados, así que escríbalo en letras GRANDES en su pantalla. Otro problema es que, como con ls, no se reconocen los puntos al principio del nombre del archivo. Para hacer frente a esto, puede usar el test "-path patrón" el cual no se preocupa acerca de los puntos y barras inclinadas cuando compara la ruta del fichero considerado con patrón.

Hemos dicho que las acciones son aquellas que realmente hacen algo. Bueno, "-prune" más bien no hace nada, es decir, al descender el árbol de directorios (a menos que se le agregue "-depth" ). Se la encuentra usualmente junto con "-fstype" , para elegir entre varios sistemas de ficheros a aquellos que deberían examinarse.

Las otras acciones pueden ser divididas en dos amplias categorías; Acciones que imprimen algo. La más obvia de estas, y en realidad, la acción por defecto de find, es "-print" que imprime el nombre del(os) fichero(s) que concuerde(n) con las otras condiciones en la línea de comandos, y devuelve verdadero. Una variante sencilla de "-print" es "-fprint archivo " , en la cual se usa archivo en vez de la salida estándar; otra es "-ls" lista el fichero en uso en el mismo formato que "ls -dils" ; "-printfformato " se comporta más o menos como la función de C printf(), para que se pueda especificar que formato debería tener la salida, y "-fprintf archivo formato " hace lo mismo, pero escribiéndolo en archivo. Estas acciones también devuelven verdadero.

_____________________________________________

8 N.T.: timestamp

Acciones que ejecutan algo. Su sintaxis es un poco extraña y su uso está muy extendido, por lo que, por favor, considérelas.

"-exec comando ";" ejecuta el comando, y la acción devuelve verdadero si el estado retornado por el comando es 0, lo que significa que la ejecución fue correcta. La razón para el ";" es bastante lógica: find no sabe donde termina el comando, y el truco de poner la acción ejecutable al final del comando no es aplicable. Bueno, la mejor manera para señalar el final del comando es usar el caracter que usa el intérprete de comandos para este fin, que es ";", pero, por supuesto, un punto y coma solo en la línea de comandos sería "comido" por el intérprete de comandos y nunca llegaría a find, así que tienen que ser precedidos de escape. La segunda cosa a recordar es como especificar el nombre del fichero en uso dentro del comando, ya que probablemente Vd. hizo todo el esfuerzo al construir la expresión para hacer algo, y no sólo para ver la hora. Esto se hace por medio de la cadena de caracteres "{}" . Algunas versiones antiguas de find requieren que coloque las llaves entre espacios en blanco (no muy práctico si Vd. necesita, por ejemplo, la ruta entera y no sólo el nombre del fichero) pero con el find de GNU podría ser cualquier lugar de la cadena de caracteres que compone el comando. ¿Y no debería estar precedido de escape o entrecomillado?, seguramente se estará preguntando. Asombrosamente, yo nunca tuve que hacer esto ni bajo tcsh ni bajo bash (sh no considera - y " como carácteres especiales, así que no es ni mucho menos un problema). Mi idea es que los intérpretes de comandos "saben" que -" no es una opción que tenga sentido, por tanto no intentan expandirlas, afortunadamente para find que puede obtenerla intacta. "-ok comando ";" se comporta como "-exec" , con la diferencia que para cada fichero seleccionado se pregunta al usuario que confirme el comando; si la respuesta empieza por y o Y, se ejecuta, de otra manera no, y la acción devuelve falso.

Hay una cierta cantidad de operadores; aquí hay una lista, en orden de prioridad decreciente.

Sí, find tiene demasiadas opciones, lo se. Pero, hay un montón de casos preparados que valen la pena recordar, porque son usados muy a menudo. Veamos algunos de ellos.

encuentra todos los nombres de fichero que empiezan con foo. Si la cadena de caracteres está incluida en el nombre, probablemente tiene más sentido escribir algo como ""*foo*"", en vez de "foo".

Es un grep ejecutado recursivamente que empieza del directorio /usr/include. En este caso, estamos interesados tanto en ficheros regulares como en enlaces simbólicos que apuntan a ficheros regulares, por tanto el test "-xtype". Muchas veces es más simple evitar especificarlo, especialmente si estamos bastante seguros cuales ficheros binarios no contienen la cadena de caracteres deseada.

(¿Y por qué el /dev/null en el comando? Es un truco para forzar al grep a escribir el fichero del nombre donde se ha encontrado un emparejamiento. El comando grep se aplica a cada fichero con una invocación diferente, y, por tanto no cree que sea necesario mostrar a la salida el nombre del fichero. Pero ahora hay dos ficheros, esto es: ¡el activo y /dev/null! Otra posibilidad podría ser redirigir la salida9 del comando a xargs y dejarle llevar a cabo el grep. Yo lo intenté, e hice pedazos completamente mi sistema de ficheros (junto con estas notas que estoy intentando recuperar a mano :-( ).

Es un trabajo clásico para la tabla de tareas preplaneadas. Borra todos los ficheros llamados core en el sistema de ficheros del tipo ext2 al cual no se ha accedido en las últimas 24 horas. Es posible que alguien quiera usar los ficheros de imagen de memoria10 para realizar un volcado post mortem, pero nadie podría recordar lo que estuvo haciendo después de 24 horas. . .

_____________________________________________

9 N.T.: to pipe

10 N.T.: core file

Es útil para ver quién tiene esos archivos que atascan el sistema de ficheros. Note el uso de "-xdev"; como sólo estamos interesados en un sistema de ficheros, no es necesario descender otro sistema de ficheros montado bajo /home.

Tenga en mente que find es un comando que consume mucho tiempo, ya que tiene que acceder a cada uno de los nodos-i del sistema para realizar su operación. Por lo tanto, es sabio combinar cuantas operaciones sean posibles en una única invocación de find, especialmente en las tareas de 'mantenimiento interno' que usualmente se administran mediante un trabajo de la tabla de tareas planificadas. Un ejemplo informativo es el siguiente: supongamos que queremos borrar los ficheros que acaban en .BAK y cambiar la protección de todos los directorios a 771 y todos los ficheros que acaban en .sh a 755. Y quizás tengamos montado el sistema de ficheros NFS en un enlace telefónico, y no queramos examinar los ficheros ahí. (¿Por qué escribir tres comandos diferentes? La manera más efectiva para realizar la tarea es ésta:

Parece feo (¡y con mucho abuso de barras invertidas!), pero mirándolo fijamente revela que la lógica subyacente es bastante sencilla. Recuerde: lo que se hace es una evaluación verdadero/falso; el comando introducido es sólo un efecto secundario. Pero esto significa que se ejecuta sólo si find puede evaluar la parte ejecutable de la expresión, esto es sólo si la parte izquierda de la subexpresión se evalúa como verdadera. Así, si por ejemplo el fichero considerado en el momento es un directorio entonces el primer ejecutable se evalúa y el permiso del nodo-i se cambia a 771; de otra manera olvida todo y pasa a la siguiente subexpresión. Probablemente, es más fácil verlo en la práctica que escribirlo; pero después de un momento, llegará a ser una cosa natural para Vd.

La leyenda dice que allá lejos en las nieblas del tiempo, cuando el primer UNIX fue creado, sus desarrolladores necesitaron un comando de bajo nivel para copiar datos entre dispositivos. Como tenían prisa, decidieron tomar prestada la sintaxis usada en las máquinas IBM-360, y desarrollar más tarde un interfaz consistente con la de los otros comandos. El tiempo pasó, y todos se acostumbraron tanto con la manera extraña de usar dd que ya ha quedado así. No se si es verdad, pero es una bonita historia para contar.

A decir verdad, dd no es totalmente distinto de los otros comandos de UNIX: es en realidad un filtro, esto es, lee por defecto de la entrada estándar y escribe en la salida estándar. Por tanto, si Vd. escribe sólo dd, la terminal se queda quieta, esperando una entrada, y un |_Ctrl-C_| es la única cosa con sentido a teclear (para cortarlo).

La sintaxis del comando es como sigue:

Todas las opciones son de la forma opción=valor. No se permite ningún espacio ni antes ni después del signo de igual; esto solía ser molesto, porque el intérprete de comandos no expandía un nombre de fichero en esta situación, pero la versión de bash presente en Linux es bastante inteligente, así que Vd. no tiene que preocuparse por eso. Es también importante recordar que todos los valores numerables (cant_bytes y cant_bloques citados arriba) pueden ser seguidos por un multiplicador.

Las opciones posibles son b para bloque, el cual multiplica por 512, k para kilobytes (1024), w para palabra (2), y xm que multiplica por m.

El significado de las opciones se explica a continuación.

_____________________________________________

11 N.T.: plain files

12 N.T.: floppy

13 N. del T.: ablocado se refiere a la característica de agrupamiento en bloques de los datos en el dispositivo.

El ejemplo canónico es con el único que Vd. probablemente ha chocado hasta ahora, cuando intentó crear el primer disco de Linux: como escribir a un disco sin un sistema de ficheros MS-DOS. La solución es simple:

Decidí no usar "ibs" porque no se cual es el mejor tamaño de bloque para un disco duro, pero en este caso no habría hecho ningún perjuicio si en vez de "obs" usara sencillamente el "bs", inclusive podría haber sido un poquito más rápido. Observe la explicación del número de sectores a escribir (18 kbyte es lo que ocupa un sector, así que "count" se pone a 80) y el uso del nombre de bajo nivel del dispositivo de la disquetera.

Otra aplicación útil de dd está relacionada con la copia de seguridad de la red. Supongamos que estamos en una máquina alfa y que en la máquina beta está la unidad de cinta /dev/rst0 con un fichero tar que estamos interesados en obtener. Tenemos los mismos privilegios en ambas máquinas, pero no hay espacio en beta para volcar 14 el fichero tar. En este caso, podríamos escribir  

para hacer en un solo paso la operación completa. En este caso, hemos usado las facilidades de rsh para realizar la lectura de la cinta. Los tamaños de entrada y salida están establecidos a los valores por defecto por estas operaciones, esto es 8 kbyte para la lectura de la cinta y 20 kbyte para la escritura en ethernet; desde el punto de vista de la otra cara del tar, hay el mismo flujo de bytes el cual podría ser obtenido de la cinta, excepto el hecho de que llega de una manera bastante errática, y la opción B es necesaria.

¡Ah! Casi lo olvidaba: No creo para nada que dd sea un acrónimo de "data duplicator", pero al menos es una manera divertida de recordar su significado. . .

_____________________________________________

14 N.T.: dump