Si Dios hubiera sabido que necesitaríamos previsión, nos la habría dado.

Una de las cosas que distinguen la filosofía de Unix es que los diseñadores de sistemas no intentaron predecir cada necesidad que los usuarios podrían tener; en lugar de eso, intentaron hacer fácil para cada usuario individual la configuración del entorno a sus necesidades particulares. Esto se consigue principalmente a través de ficheros de configuración. También son conocidos como "ficheros de inicio" , "ficheros rc" (por "run control", control de arranque), o incluso "ficheros punto (dot files)", porque los nombres de los ficheros siempre empiezan con ".". Recordemos que los ficheros que empiezan por "." no se visualizan normalmente con ls.

Los ficheros de configuración más importantes son los usados por el shell. El shell por defecto de Linux es el bash, y éste es el shell que cubre este capítulo. Antes de empezar a explicar cómo personalizar el bash, tenemos que saber cuales son los archivos que mira.

Hay diferentes modos de funcionamiento del bash. Puede funcionar como shell de ingreso, que es el modo en que arranca cuando se ingresa por primera vez. El shell de ingreso debería ser el primer shell que vea.

Otro modo en que puede funcionar bash es como shell interactivo. Este es un shell que presenta un prompt a un humano y espera una entrada de datos. Un shell de ingreso también es un shell interactivo. Una manera de conseguir un shell interactivo sin ingresar en el sistema es, por ejemplo, un shell dentro de xterm. Cualquier shell que sea creado por otro medio distinto del ingreso registrado en el sistema es un shell de no-ingreso.

Finalmente, hay shells no interactivos. Estos shells se usan para ejecutar un archivo de comandos, muy parecidos a los ficheros de procesamiento por lotes del MS-DOS, los archivos que acaban en .BAT. Estas macros de shell funcionan como mini-programas. Aunque son usualmente mucho más lentos que un programa normal compilado, suele ser cierto también que son mucho más fáciles de escribir. Dependiendo del tipo de shell, se usarán distintos tipos de archivo al arrancarlo:

Como muchos usuarios quieren tener mayormente el mismo entorno, sin importar que tipo de shell interactivo acaben teniendo, y sea o no un shell de ingreso, empezaremos nuestra configuración poniendo un comando muy simple en nuestro archivo .bash_profile: "source ~/.bashrc". El comando source ordena al shell que interprete el argumento como una macro de shell. Lo que significa para nosotros es que cada vez que .bash_profile se ejecuta, también se ejecuta .bashrc. Ahora, sólo añadiremos comandos a nuestro archivo .bashrc. Si alguna vez queremos que se ejecute un comando únicamente cuando hemos hecho un ingreso registrado, lo añadiremos a nuestro .bash_profile.

¿Cuales son algunas de las cosas que interesaría personalizar? Esto es algo que creo que el 90% de los usuarios de Bash han puesto en su .bashrc:

Este comando define un alias de shell llamado ll que "expande" el comando normal de shell "ls -l" cuando se invoca por el usuario. De modo que, asumiendo que Bash ha leído este comando del fichero .bashrc, podemos teclear ll para conseguir el efecto de "ls__-l"_ con solo la mitad de pulsaciones. Lo que ocurre es que cuando tecleamos "ll" y pulsamos |_Intro_|, Bash lo intercepta, lo reemplaza por "ls -l" , y ejecuta éste en su lugar. No hay ningún programa llamado ll en el sistema, pero el shell automáticamente traduce el alias a un programa válido.

Hay algunos alias de ejemplo en la figura 9.1.3. Puede ponerlos en su propio .bashrc. Uno especialmente interesante es el primero. Con él, cada vez que alguien teclea "ls" , automaticamente tiene una opción "-F" añadida. (El alias no intenta expandirse a sí mismo otra vez). Este es un modo muy común de añadir opciones que se usan constantemente al llamar a un programa.

Nótese los comentarios con el caracter "#" en la figura 9.1.3. Cada vez que aparece un "#", el shell ignora el resto de la línea.

Quizá haya notado unas cuantas cosas sueltas sobre los ejemplos. Primero, me he dejado las comillas en algunos de los alias como pu. Estrictamente hablando, las comillas no son necesarias cuando sólo se tiene una palabra a la derecha del signo igual.

Figura 9.1 Algunos alias de ejemplo para bash.

Pero no hace daño poner comillas, así que no me dejéis crearos malos hábitos. Ciertamente habrá que usarlas si se va a crear un alias de un comando con opciones y/o argumentos:

Además, el último alias tiene algún entrecomillado gracioso:

Como es fácil suponer, he querido pasar entrecomillados dentro de las opciones, así que tengo que anteponerles una contrabarra para que bash no crea que ya ha llegado al final del alias.

Finalmente, he creado dos alias de dos errores de escritura comunes, "mroe" y "moer", apuntando al comando que pretendía escribir, more. Los alias no interfieren con el paso de argumentos a un programa. Lo siguiente funciona bien:

De hecho, saber como crear sus propios alias es probablemente por lo menos la mitad de las personalizaciones que hará jamás. Experimente un poco, descubra cuáles son los comandos largos que teclea frecuentemente, y cree alias para ellos. De esta manera, le resultará más confortable trabajar con el prompt del shell.

Otra cosa que uno hace frecuentemente en .bashrc es definir variables de entorno. Y >qué son las variables de entorno? Vamos a mirarlo desde otra dirección: Supongamos que está leyendo la documentación del programa fruggle, y se encuentra con una de estas expresiones:

Fruggle normalmente busca su fichero de configuración, .frugglerc, en el directorio raíz del usuario. Sin embargo si la variable de entorno FRUGGLEPATH indica un nombre de archivo diferente, mirará ahí en su lugar.

Cada programa se ejecuta en un entorno, y ese entorno es definido por el shell que llamó al programa1. Se puede decir que el entorno existe "dentro" del shell. Los programadores tienen una rutina especial para interrogar al entorno, y el programa fruggle usa esa rutina. Comprueba el valor de la variable de entorno FRUGGLEPATH. Si esa variable no está definida, sencillamente usará el archivo .frugglerc del directorio raíz. Si está definida, usará el valor de esa variable (que debe ser el nombre de un archivo que fruggle pueda usar) en lugar del archivo por defecto .frugglerc. Así es como se puede cambiar el entorno en bash:

Hay que pensar en el comando export con este significado: "Por favor exporta esta variable fuera del entorno donde estaré llamando programas, de modo que su valor sea visible para ellos." Realmente hay razones para llamarlo export, como se verá después.

Esta variable en particular es usada por el infame programa de encriptación mediante clave pública de Phil Zimmerman, pgp. Por defecto, pgp usa el directorio raíz como lugar para encontrar determinados archivos que necesita (que contienen claves de encriptación), y también un lugar para guardar archivos temporales que crea mientras está en marcha. Al darle este valor a la variable PGPPATH, le he dicho que use el directorio /home/larry/secrets/pgp en lugar de /home/larry.

He tenido que leer el manual de pgp para encontrar el nombre exacto de la variable y lo que hace, pero es bastante estándar el uso del nombre del programa en mayúsculas, seguido del sufijo "PATH". También es útil saber como preguntar al entorno:

Nótese el "$"; se precede la variable de entorno con un signo de dólar para extraer el valor de la variable. Si lo hubiera escrito sin el signo de dólar, echo simplemente habría mostrado su(s) argumento(s):

El "$" se usa para evaluar variables de entorno, pero sólo lo hace dentro del contexto del shell, o sea, cuando el shell está interpretando. ¿Cuando está el shell interpretando? Bueno, cuando se escriben comandos en el prompt, o cuando bash está leyendo comandos de un archivo como .bashrc, se puede decir que está "interpretando" los comandos.

_____________________________________________

1 Ahora se puede comprobar porqué los shells son tan importantes. <No hay que andar pasando un entorno completo a mano cada vez que se llame a un programa!

Figura 9.2 Algunas variables de entorno importantes.

Hay otro comando muy útil para preguntar al entorno: env". env enseñará un listado de todas las variables de entorno. Es posible, especialmente si se usa X, que la lista se salga de la pantalla.

Si esto ocurre, hay que canalizar env a través de more: "env _ more".

Unas cuantas de estas variables pueden ser muy útiles, así que las comentaremos. Mire la Figura 9.1.4. Estas cuatro variables están definidas automáticamente cuando se ingresa en el sistema: no se definen en .bashrc o .bash_login.

Vamos a echar un vistazo más de cerca a la variable TERM. Para comprenderla, vamos a mirar hacia atrás en la historia del Unix: El sistema operativo necesita conocer ciertos datos sobre su consola para poder realizar funciones básicas, como escribir un carácter en la pantalla, mover el cursor a la línea siguiente, etc. En los primeros días de los ordenadores, los fabricantes estaban continuamente añadiendo nuevas características a sus terminales: primero el vídeo inverso, luego quizás juegos de caracteres europeos, eventualmente incluso primitivas funciones de dibujo (hay que recordar que éstos eran los tiempos anteriores a los sistemas de ventanas y el ratón). Pero todas estas funciones representaban un problema para los programadores: ¿Cómo iban a saber lo que un terminal podía soportar y lo que no? Y ¿cómo podían emplear nuevas características sin convertir los viejos terminales en inservibles?

En Unix, la respuesta a estas cuestiones fue /etc/termcap . /etc/termcap es una lista de todos los terminales que un sistema conoce, y como controlan el cursor. Si un administrador de sistema consigue un terminal nuevo, todo lo que tiene que hacer es añadir una entrada para ese terminal en /etc/termcap en lugar de recompilar todo el Unix. A veces es incluso más simple. Al pasar el tiempo, el vt100 de Digital Equipment Corporation se convirtió en un pseudo-estándar, y muchos nuevos terminales fueron construidos para que pudieran emularlo, o comportarse como si fueran un vt100.

Bajo Linux, el valor de TERM es a veces console, un clónico de vt-100 con algunas características añadidas.

Otra variable, PATH, es también crucial para el funcionamiento correcto del shell. Aquí está la mía:

El PATH es una lista, separada por el carácter dos puntos ":", de los directorios donde el shell buscará el nombre del programa a ejecutar. Cuando yo tecleo "ls" y pulso |_Intro_|, por ejemplo, Bash primero busca en /home/larry/bin, un directorio que he hecho para guardar los programas que escribo. Pero yo no he escrito ls (de hecho, ¡creo que se escribió antes de que yo naciera!). Como no lo encuentra en /home/larry/bin, Bash mira después en /bin ¡y ahí hay una coincidencia! /bin/ls existe y es ejecutable, de modo que Bash deja de buscar un programa llamado ls y lo arranca. Podría haber habido perfectamente otro ls esperando en el directorio /usr/bin, pero bash nunca lo ejecutará si no lo pido especificando una ruta de directorios explícita:

La variable PATH existe para no tener que teclear rutas de directorio completas para cada comando. Cuando se escribe un comando, Bash lo busca en los directorios nombrados en el PATH, en orden, y si lo encuentra, lo ejecuta. Si no lo encuentra, devuelve un descortés mensaje de error:

Notar que en mi PATH no existe el directorio actual, ".". Si estuviera, tendría este aspecto:

Esto es asunto de debate en los círculos de Unix (de los cuales ahora es miembro, le guste o no). El problema es que tener el directorio actual en el path puede ser un agujero en la seguridad. Supongamos que entramos en un directorio en el que alguien ha dejado un "Caballo de Troya" llamado ls, y hacemos un ls, como es natural después de entrar en un directorio nuevo. Como el directorio actual, ".", viene primero en nuestro PATH, el shell encontrará esta versión de ls y la ejecutará. Sea cual sea el daño que hayan puesto en ese programa, lo acabamos de activar (y puede ser un montón de daño). Quien fuera no necesita permisos de root para hacerlo; sólo hace falta permisos de escritura en el directorio donde se encuentra el "falso" ls. Incluso podría ser su propio directorio home, si sabe que vamos a estar husmeando por ahí en algún momento.

En su propio sistema, es muy improbable que las personas se estén dejando trampas unas a otras. Pero en un gran sistema multiusuario (como muchos ordenadores de universidades), hay un montón de programadores hostiles con los que nunca se ha encontrado. Que quiera tentar a la suerte o no teniendo "." en el path depende de la situación; no voy a ser dogmático en ningún sentido, sólo quiero informar de los riesgos implícitos2. Los sistemas multiusuario son verdaderas comunidades, donde la gente puede hacerles cosas a los demás en todo tipo de maneras nunca vistas.

El modo en que he dejado mi PATH incluye la mayoría de lo que se ha aprendido hasta ahora sobre variables de entorno. Esto es lo que hay actualmente en mi .bashrc:

export PATH=$-PATH":.:$-HOME"/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin

_____________________________________________

2 Recuérdese que siempre se puede ejecutar un programa en el directorio actual siendo explícito, p.ej.: "./foo".

Me aprovecho de que la variable HOME se activa antes de que Bash lea el fichero .bashrc, usando su valor en la construcción del PATH. Las llaves ("{...}") son un nivel añadido de cita; delimitan el tamaño de lo que va a evaluar "$", de modo que el shell no se confunda por culpa del texto inmediatamente posterior ("/bin" en este caso). Aquí hay otro ejemplo del efecto que tienen:

Sin las llaves, no connseguiría nada, porque no hay ninguna variable de entorno llamada HOMEfoo.

Quisiera aclarar una cosa en este path: el significado de "$PATH". Lo que hace es incluir el valor de cualquier variable PATH previamente activada en mi nuevo PATH. ¿Dónde se habrá activado la variable anterior? El archivo /etc/profile sirve como una especie de .bash_profile global, común a todos los usuarios. Tener un archivo centralizado como este hace más sencillo para el administrador del sistema añadir un directorio nuevo al PATH de todo el mundo, sin que cada uno tenga que hacerlo individualmente. Si se incluye el path antiguo en el nuevo, no se perderán ninguno de los directorios que el sistema ya haya preparado.

También se puede controlar como aparece el prompt. Esto se consigue mediante la variable de entorno PS1. Personalmente, quiero un prompt que me indique el path del directorio actual así es "como lo hago en mi .bashrc:

Como se puede ver, en realidad se usan dos variables. La que se activa es PS1, y toma el valor de PWD, que puede ser interpretada como "Print Working Directory" (imprime el directorio de trabajo) o "Path to Working Directory"(trayectoria al directorio de trabajo). Pero la evaluación de PWD tiene lugar entre apóstrofos agudos. Estos apóstrofos sirven para evaluar la expresión en su interior, la cual a su vez evalúa la variable PWD. Si sólo hubiéramos hecho "export PS1=$PWD" , nuestro prompt nos habría mostrado constantemente el path del directorio de trabajo en el momento en que PS1 fue activada, en lugar de actualizarse constantemente mientras cambiamos de directorios. Bueno, es un poco confuso, y no muy importante en realidad. Sólo hay que tener en cuenta que se necesita esa clase de apóstrofos si se quiere mostrar el directorio actual en el prompt.

Quizá se prefiera "export PS1='$PWD>'" , o incluso el nombre del sistema:

Diseccionemos este ejemplo un poco más. Aquí se usa un nuevo tipo de literal, el apóstrofo grave. Esta clase de literal no protege nada, de hecho, 'hostname' no aparece en ninguna parte del prompt cuando intentamos arrancarlo. Lo que sucede realmente es que se evalúa el comando dentro de los apóstrofos graves, y el resultado se guarda en lugar del nombre del comando entrecomillado.

Probemos con "echo `ls`" o "wc `ls`" . A medida que se consiga más experiencia usando el shell, esta técnica se hace más y más potente.

Hay mucho más por comentar de como se configura el fichero .bashrc, y aquí no hay bastante espacio para hacerlo. Se puede aprender más leyendo la página man de bash, o preguntando a usuarios experimentados. Aquí hay un .bashrc completo para poder estudiarlo; es razonablemente estándar, aunque el path es un poco largo.

Mucha gente prefiere trabajar dentro de un entorno gráfico, y para las máquinas bajo Unix eso suele significar usar X. Si se está acostumbrado al Macintosh o al Microsoft Windows, puede costar un poco acostumbrarse al sistema X Window, especialmente al modo en que se configura.

Con Macintosh o Microsoft Windows, se personaliza el entorno desde dentro: si se quiere cambiar el fondo, por ejemplo, se pulsa con el ratón sobre el nuevo color en algún programa gráfico especial de configuración. En X, las opciones por defecto del sistema se controlan mediante ficheros de texto, que se editan directamente, en otras palabras, se escribe el nombre del color en un fichero para cambiar el color del fondo.

No se puede negar que este método no es tan llano como el de algunos sistemas de ventanas comerciales. Creo que esta tendencia a permanecer basado en texto, incluso en un entorno gráfico, tiene mucho que ver con el hecho de que X fué creado por un puñado de programadores que simplemente no estaban tratando de escribir un software que pudieran usar sus abuelos. Esta tendencia puede cambiar en futuras versiones de X (por lo menos así lo espero3), pero por ahora, hay que aprender como entenderse con unos cuantos ficheros de texto más. Por lo menos nos da un control muy flexible y preciso de nuestra configuración.

Aquí están los ficheros más importantes para configurar X:

Todos estos ficheros deberían estar en el directorio $HOME, si es que existen.

.xinitrc es una macro de shell muy simple que se ejecuta cuando invocamos a X. Puede hacer cualquiera de las cosas que pueden hacer otras macros de shell, pero por supuesto su uso principal es arrancar varios programas de X y establecer parámetros del sistema de ventanas. El último comando en .xinitrc es usualmente el nombre de un gestor de ventanas a ejecutar, por ejemplo /usr/bin/X11/twm.

¿Qué tipo de cosas nos gustaría poner en .xinitrc? Quizá algunas llamadas al programa xsetroot, para hacer que la ventana de fondo (escritorio) y el ratón tengan el aspecto que deseamos. Llamadas a xmodmap, que informa al servidor4 de como interpretar las señales del teclado.

_____________________________________________

3 N. del T.: Yo también ;-)

4 El "servidor" sólo se refiere al proceso principal en la máquina, con el que todos los demás programas de X tienen que comunicar para usar la pantalla. Estos otros programas se conocen como "clientes", y todo el paquete se llama "sistema cliente-servidor".

O cualquier otro programa que se quiera iniciar cada vez que se arranque X (por ejemplo, xclock). Aquí está una parte de mi .xinitrc; el suyo seguramente será distinto, así que hay que tomárselo sólo como ejemplo:

Nótese que algunos comandos son iniciados en segundo plano (p.ej.: los que van seguidos de "&"), mientras que otros no lo son. La distinción está en que algunos programas se iniciarán cuando arranquemos X y seguirán en marcha hasta que salgamos. Los otros se ejecutan una vez y se cierran inmediatamente. xsetroot es uno de éstos; sólo establece la ventana principal o el cursor a lo que sea, y luego se cierra.

Una vez que el gestor de ventanas ha arrancado, leerá su propio fichero de inicio, que controla cosas como la composición de los menús, en qué posiciones se presentan las ventanas cuando se abren, control de iconos, y otros asuntos terriblemente importantes. Si se usa twm, el fichero es .twmrc en nuestro directorio home. Si se usa fvwm, el fichero es .fvwmrc, etc. Explicaremos sólo estos dos, ya que son los gestores de ventanas que más frecuentemente se encontrarán con Linux.

.twmrc no es una macro de shell_está escrito en un lenguaje especialmente hecho para twm, ¡créalo o no!5 Principalmente, a la gente en su .twmrc le gusta jugar con los estilos de la ventana (colores y demás), y hacer interesantes menús, así que ahí va un .twmrc de ejemplo:

_____________________________________________

5 Éste es uno de los problemas de los ficheros de configuración: normalmente usan su propio lenguaje de comandos. Esto significa que los usuarios se vuelven muy buenos a la hora de aprender lenguajes nuevos rápidamente. Supongo que habría estado bien que los primeros programadores de Unix se hubieran puesto de acuerdo en algún estándar de fichero de inicio, pero para ser justo es difícil de predecir que tipo de informaciones necesitarán los programas.

¡Guau! Creedme, este no es el .twmrc más largo que he llegado a ver. Es probable que con vuestra versión de X vinieran algunos ejemplos de archivos .twmrc bastante decentes. Se pueden buscar dentro del directorio /usr/lib/X11/twm/ o en /usr/X11/lib/X11/twm.

Un defecto de programa que hay que vigilar en los ficheros .twmrc es no olvidarse de poner el "&" después de un comando en un menú. Si se nota que X se cuelga cuando se usan ciertos comandos, lo más probable es que ésta sea la causa. Hay que salir de X con |_Ctrl_|-|_Alt_|-|_Retroceso_|, editar .twmrc, y probar otra vez.

Si se usa fvwm, el directorio /usr/lib/X11/fvwm/ (o /usr/X11/lib/X11/fvwm/) tiene algunos ejemplos de ficheros de configuración.

[Compañeros: No sé nada sobre fvwm, aunque supongo que sacaré algo en claro de los ficheros de ejemplo, igual que el lector :-). Además, dado el pequeño pero decente system.twmrc en el directorio arriba mencionado, me pregunto si vale la pena que de este largo ejemplo con mi propio .twmrc. De momento está aquí, pero no sé si lo dejaremos o no.-Karl]

Otros ficheros de inicio dignos de mención son:

Si se usa emacs como editor principal, entonces el fichero .emacs es muy importante. Se discute con extensión en el Capítulo 8.

El fichero .netrc permite tener ciertas configuraciones por defecto cada vez que se arranca ftp. Aquí hay un pequeño .netrc de ejemplo:

Cada línea de .netrc especifica un nombre de máquina, un nombre de cuenta de acceso a usar por defecto con esa máquina, y una contraseña. Esto es muy útil si se usa ftp continuamente y se está harto de teclear el nombre de acceso y la contraseña en cada uno. El programa de ftp intentará acceder automáticamente usando los datos del fichero .netrc, si se hace ftp a una de las máquinas listadas allí.

Se puede obligar a ftp a ignorar el fichero .netrc y no intentar acceder de manera automática, arrancándolo con la opción "-n" : "ftp -n" .

Hay que asegurarse de que el fichero .netrc sólo es legible por el usuario. Se puede usar el programa chmod para establecer los permisos de lectura. Si otra gente puede leerlo, significa que pueden encontrar su contraseña de acceso a varios otros ordenadores. Esto es un agujero en la seguridad tan grande como uno pueda tenerlo. Como recomendación para ser cuidadoso, ftp y otros programas que miran el fichero .netrc no funcionarán si los permisos de lectura del fichero son incorrectos.

Hay mucho más sobre el fichero .netrc de lo que se ha explicado aquí. Cuando se tenga una oportunidad, hay que probar "man .netrc" o "man ftp".

Si tiene un fichero .rhosts en su directorio $HOME, le permitirá usar programas en esta máquina de forma remota. Por ejemplo, se puede estar registrado en la máquina cs.oberlin.edu, pero con un .rhosts correctamente configurado en floss.life.uiuc.edu, se puede usar un programa en floss y presentar el resultado en cs, sin tener que registrarse o teclear una contraseña frente a floss.

El archivo .rhosts se ve más o menos así:

El formato es muy directo: un nombre de máquina, seguido de un nombre de usuario. Supongamos que este ejemplo es en realidad mi archivo .rhosts en floss.life.uiuc.edu. Esto significaría que puedo usar programas en floss, y ver el resultado en cualquiera de las máquinas listadas, siempre y cuando yo esté también registrado como el usuario correspondiente a cada máquina cuando intento ejecutar el programa.

El mecanismo exacto con el que uno usa un programa remoto es normalmente el programa rsh. Significa "remote shell"(shell remoto), y lo que hace es iniciar un shell en la máquina remota y ejecutar el comando especificado. Por ejemplo:

El usuario "trixie" en "floss.life.uiuc.edu", que tenía el fichero .rhosts de ejemplo mostrado antes, permite explícitamente a "trixie" en "frobbo.hoola.com" usar programas como si fuera "trixie" de "floss".

No hay porqué tener el mismo nombre de usuario en todas las máquinas para que .rhosts funcione. Se puede usar la opción "-l" con rsh para especificar a la máquina remota cual nombre de usuario se quiere usar para registrarse. Si ese nombre existe en la máquina remota, y tiene un fichero .rhosts con el nombre de la máquina local y el nombre de usuario correspondiente, entonces la orden incluida con rsh se ejecutará.

Esto funcionará si el usuario "larry" en "floss.life.uiuc.edu" tiene un fichero .rhosts que permite a "trixie" de "frobbo.hoopla.com" usar programas en su cuenta. Si son o no la misma persona es irrelevante: la única cosa importante son los nombres de usuario, los nombres de las máquinas y la fila referente a "floss" en el .rhosts de Larry. Nótese que el fichero .rhosts de Trixie en frobbo no importa, sólo cuenta el de la máquina remota.

Hay otras combinaciones que se pueden poner en un fichero .rhosts, por ejemplo, se puede dejar en blanco el nombre de usuario detrás del nombre de una máquina remota, para permitir a cualquier usuario de esa máquina que ejecute programas en la máquina local. Esto es, por supuesto, un riesgo en la seguridad: alguien podría ejecutar remotamente un programa que borre mis archivos, por el simple hecho de tener una cuenta en cierta máquina. Si se va a hacer cosas como esta, entonces hay que asegurarse de que el fichero .rhosts es legible sólo por el usuario implicado, y por nadie más.

También se puede tener un fichero .forward, el cual no es un fichero de configuración estrictamente hablando. Si contiene direcciones de e-mail, entonces todo el correo que llegue al usuario se redirigirá a esas direcciones. Esto es útil cuando se tienen cuentas en varios sistemas, pero se quiere leer el correo desde un solo sitio.

Hay una gran cantidad de otros ficheros de configuración posibles. La cantidad exacta variará de sistema a sistema, y depende de los programas instalados. Una manera de saber más es mirar todos los archivos en el directorio $HOME que empiecen por ".". No es seguro que todos sean ficheros de configuración, pero seguro que la mayoría sí lo es.

El ejemplo definitivo que puedo dar es mostrar un sistema Linux en funcionamiento. Así que, si tenéis acceso a Internet, estáis invitados a hacer telnet a floss.life.uiuc.edu. Registráos como "guest", contraseña "explorer", y husmead por dentro. Muchos de los archivos de ejemplo se pueden encontrar en /home/kfogel, pero también hay otros directorios de usuarios. Sois libres de copiar cualquier cosa que se pueda leer. Por favor tened cuidado: floss no es un sitio terriblemente seguro, y ciertamente se puede conseguir acceso como 'root' si uno lo intenta lo suficiente. Prefiero creer en la confianza, más que en la vigilancia constante, para mantener la seguridad.