HAL y dict

dict fue el paquete agraciado con el premio de poder ser a partir de ahora un ayudante más en el selecto grupo de colaboradores de HAL.

Pero, antes de proceder a su investidura, no está de más resumir el proceso completo de su selección. Se verá que las tareas que se llevaron a cabo para realizarla consumen bastante menos tiempo de lo que lleva leer y asimilar los tres artículos anteriores. Para completar el proceso, añadiré al final la única tarea no realizada todavía, la instalación propiamente dicha. [Destacaré en negrita la orden principal de cada paso]:

1. Buscamos, sin éxito, órdenes relacionadas con el término 'diccionario':
   

       apropos dicitionary



2. Buscamos paquetes relacionados con los términos 'diccionario' y 'línea de comandos'. La búsqueda se centró en las etiquetas de los paquetes:
   

       aptitude search '~Gdictionary ~Gcommandline'



3. Procedimos a una criba manual del resultado obtenido, que guardamos en el fichero llamado 'candidatos', y obtuvimos información de los candidatos guardados en ese fichero [A diferencia del día pasado voy a suponer que la lista contenida en el fichero 'candidatos' consistió en la serie de los nombres de paquetes separados por espacios, que hubiese sido la forma lógica de esa lista, de no haber tenido que explicarla y presentarla en un navegador]:
   

       aptitude show  $(cat candidatos) | more



4. Y el paso final, el que toca hoy hacer. Instalamos el paquete resultante de nuestra criba. Para efectuar esta operación tenemos que ser root [quien usa sudo en lugar de su, sustituya sudo por su -c en la orden siguiente y quite las comillas; quien usa su, lea la ayuda de su relativa a la opción -c]:
   

       su -c 'aptitude install dict'

Y ahí está dict, dispuesto a que empecemos a asignarle su tarea. Pero antes habrá que conocerlo en persona y saber de él lo suficiente. Cuando instalamos un paquete nuevo no sabemos de él más que lo que aptitude show nos dice, es decir, algo así como su curriculum. Pero de ahí a ponerlo a trabajar en el papel para el que fue instalado hay un trecho.

Lo más recomendable para trabar un conocimiento eficaz con un paquete nuevo es ir de inmediato a la ayuda incluida en el propio paquete. Sí, un paquete consta de varias cosas, aparte del programa o programas que agrupa, entre ellas está una ayuda inicial. Esta ayuda puede ser de dos tipos: en primer lugar, la que redacta la persona o personas que crearon el paquete (los mantenedores) y que suele versar sobre cuestiones específicas de nuestra distribución; en segundo lugar, la ayuda que el propio creador haya proporcionado y que el mantenedor del paquete incluirá dentro de él. En el caso de distribuciones basadas en Debian esta ayuda y otro tipo de documentación, que no vamos a comentar, se encuentra bajo el directorio
/usr/share/doc/[nombre_del_paquete].

Veamos pues que hay en el directorio correspondiente a dict. Para ello debemos pedirle a HAL algo que todavía no hemos hecho nunca, que nos dé una lista del contenido de ese directorio.

HAL, dame una lista del contenido de /usr/share/doc/dict

O, en breve,

lista /usr/share/doc/dict

Que en lengua de HAL se dice así:

ls /usr/share/doc/dict

No me gusta demasiado como sale en mi pantalla la respuesta. Así es que voy a matizar la solicitud inicial para que HAL me la presente con cada ítem en una línea distinta:

ls -1 /usr/share/doc/dict

El resultado de esta última orden es el siguiente:

changelog.Debian.gz
changelog.gz
copyright
examples
NEWS.Debian.gz
NEWS.gz
README.Debian.gz


Todavía no sé con exactitud si todo el contenido del directorio son ficheros o hay también subdirectorios u otras cosas. Le añadiré un matiz más a mi consulta anterior de modo que sepa también qué tipo de ítem es cada uno de los ingredientes del directorio:

ls -1 -F /usr/share/doc/dict

Lo que me devuelve:

changelog.Debian.gz
changelog.gz
copyright
examples/
NEWS.Debian.gz
NEWS.gz@
README.Debian.gz


Vaya. Han surgido dos nuevos signos. ¿Qué significan? El sentido de el caracter / es obvio, señala que examples es un directorio. El del carácter @ no es deducible sin leer la página de manual ls(1). Tras consultarla descubrimos que la @ indica que NEWS.gz es un enlace simbólico. Dejemos el tema de los enlaces simbólicos para otra ocasión y sigamos adelante.

Todos los ficheros "normales" que hay en /usr/share/doc/dict terminan con .gz. Sin entrar en detalles, este sufijo indica que se trata de ficheros comprimidos. Un fichero comprimido es el resultado de someter un fichero cualquiera a un proceso de compresión para reducir su tamaño. Por ejemplo, un fichero de audio se puede comprimir de varias maneras, una de ellas da como resultado los conocidos ficheros mp3. También se pueden comprimir ficheros de texto para que ocupen menos espacio en disco. Es el caso de los ficheros que nos ocupan.

Ahora bien, no podremos ver estos ficheros sin herramientas especiales. Por ejemplo, no nos valdrá la ya utilizada orden more para visualizar su contenido. O sí, veremos algo, pero se tratará de un galimatías. Órdenes como more (que, técnicamente, se denominan paginadores) disponen de variantes específicas para la visualización de ficheros comprimidos. En el caso de more la variante es zmore.

¡Vale! ¿Pero qué ficheros paginamos? ¿Contienen todos la ayuda sobre dict que estamos buscando?

No. Como ya dije el contenido del directorio /usr/share/doc/[paquete] puede constar de varias clases de información. Nosotros nos vamos a ceñir sólo a lo que nos interesa, la ayuda inicial. (Dejo que el lector curioso investigue por su cuenta en los ficheros que no comentaremos aquí). Un nombre de fichero típico para designar la ayuda previa es LEEME, o, en inglés, README. En el caso de dict tenemos un fichero con ese nombre, más el añadido '.Debian', lo que indica que es un fichero específico de nuestra distribución, creado por el mantenedor del paquete. Veamos qué nos quiere decir la persona que ha producido este paquete para nosotros, pidámosle a HAL que nos muestre el fichero comprimido README.Debian.gz:

zless README.Debian.gz

La salida ---que omito--- contiene bastante cosas que no sabemos de qué van. Esta es una situación típica. Nos habrá pasado, sin duda, al leer las páginas del manual. Es crucial ---lo repito, es crucial--- que no arrojemos la toalla en estas situaciones. Debemos seguir leyendo y tratando de entender lo que podamos, lo que esté a nuestro alcance. Sólo el contacto continuo con el lenguaje técnico va a permitirnos avanzar. El mundo extraño que al principio nos plantea se irá aclarando poco a poco con el tiempo. Así hemos empezado todos, incluidos los gurus. La gran diferencia entre el usuario zoquete y el amigo de HAL no tiene que ver con la inteligencia, sino con el carácter. La pereza, el pesimismo, el conformismo y cosas de ese estilo son la causa de muchos males y entre otros de la ineficacia y ramplonería en el uso de las computadoras. No caigas, lector, en los vicios de los bobalicones y aguanta el tipo, también cuando no entiendas nada.

Rescatemos un párrafo del fichero README.Debian.gz [lo vierto al castellano]:

El fichero de configuración por defecto hace que dict trate de acceder al servidor dictd en el host local. Si esto falla, dict intentará acceder a un servidor público en el sitio de Internet dict.org. Se debe estar conectado a Internet para poder acceder al servidor público; el cliente dict no establecerá de forma automática la conexión.

De este párrafo aprendemos lo siguiente:

• dict funciona según lo establece un fichero de configuración. [Nada nuevo. Ya hablamos de los ficheros de configuración hace tiempo.]


• dict funciona en modo cliente-servidor.


• Si no tocamos el fichero de configuración, dict accederá primero al servidor local (dentro de nuestra máquina) y en caso contrario a un servidor remoto de Internet abierto al público.


• Hay que estar conectado a Internet para poder acceder al servidor remoto. [Bastante natural]

Lo único oscuro de estas explicaciones tiene que ver con lo de cliente y servidor. Como se trata de un concepto capital de la ciencia informática, conviene comprender, al menos intuitivamente, de qué va el asunto.

Para poder leer esta página web que estamos leyendo ahora, nuestro navegador (el cliente web) ha tenido que pedírsela a la maquina donde la página reside. Nuestra solicitud ha atravesado multitud de máquinas y ha llegado finalmente a su destino. La máquina que aloja la página posee un encargado para atender a cualquier solicitud de este tipo. Fue este encargado (el servidor web) el que nos ha remitido la página de vuelta. Imaginemos que creamos un sitio web y lo alojamos en nuestra máquina. Cuando nuestro navegador quiere visitar ese sitio su solicitud será atendida por un encargado (un servidor web) instalado dentro de nuestra máquina misma. En este último caso no habrá necesidad de estar conectado a Internet, porque nuestra solicitud se gestionará dentro de nuestra máquina y no tendrá que atravesar máquinas externas para ser atendida.

Este tipo de arquitectura cliente-servidor es común a muchos servicios, además de la Web. Da igual que lo que se solicite sea una página web o una entrada de diccionario o cualquier otra cosa imaginable. En una arquitectura cliente-servidor una parte (el cliente) hace las veces del solicitante y la otra (el servidor) la del encargado de atender las solicitudes. Tanto cliente como servidor hablan el mismo idioma y se comportan siguiendo convenciones conocidas por ambos.

En el caso que nos ocupa el cliente es dict y el servidor dictd. El servidor puede ser local (puede estar en nuestra propia máquina) o puede ser remoto (estar en una máquina de la organización dict.org). Si dict no encuentra lo que busca en nuestra máquina ---porque nuestra máquina no contenga los diccionarios correspondientes, que hay que instalar aparte--- lo buscará en dict.org.

Hasta aquí está claro, y esto es lo que, por el momento, nos enseña el fichero README.Debian.gz sobre dict.

Como esta vez no vamos a modificar ningún fichero de configuración ni a instalar paquetes de diccionario para el servidor local dictd, confiamos en que nuestra consultas sobre artículos de diccionario sean resueltas por servidores remotos.

Pero aún nos queda conocer cómo realizar la consulta propiamente dicha, es decir, cómo pedirle a HAL que se valga de dict para realizar consultas en diccionarios remotos.

Ahí es donde empieza el camino conocido: la lectura de la página de manual de dict. Lo veremos el día próximo.


Resumen:

• Un paquete está constituido por multitud de ficheros. Además de los programas propiamente dichos, las páginas de manual, etc., suele contener alguna clase de información básica sobre sí mismo. En los paquetes Debian esta información se encuentra bajo el directorio genérico /usr/share/doc/ y es un buen punto de partida para obtener información inicial sobre el paquete, más allá de la que proporciona aptitude show.


• La orden ls permite listar el contenido de un directorio.


• Un fichero comprimido es un fichero cualquiera sometido a un proceso de compresión para reducir su tamaño.


• Existen variantes específicas de los paginadores habituales, que permiten visualizar ficheros de texto comprimidos. En el caso de more esta variante es zmore.


• Un gurú es alguien que no tuvo miedo, pereza o desconfianza ante lo desconocido y que, a fuerza de ilusión, tesón y paciencia llegó a convertirse en un maestro.


• La arquitectura cliente-servidor es omnipresente en las redes de computadoras. Consiste en una aplicación distribuida en dos partes, la parte cliente realiza solicitudes que la parte servidor responde. La comunicación entre cliente y servidor se realiza en base a una serie de convenciones y comportamientos tipificados conocidos por ambos.


• La aplicación dict es un caso de arquitectura cliente-servidor.