%***********************************************************************
%
%       Spanish Translation by:  Richy,
%                                richy@millorsoft.es
%
%       Revisado (cballard)      Jun 19, 1997
%
%***********************************************************************
% kff: ¿Qué mas deberia explicar? ¿Se te ocurre algo?

\chapter{¡Tengo que ser yo mismo!}\label{configuration-chapter}

\begin{quote}
  Si Dios hubiera sabido que necesitaríamos previsión, nos la habría
  dado.
\end{quote}

\section{Personalización del \cmdnm{bash}}

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 {\bf
  ficheros de configuración}\index{ficheros de configuracion}.
También son conocidos como ``ficheros de inicio'' \index{ficheros de
  inicio}, ``ficheros rc''\index{ficheros rc } (por ``run control'',
control de arranque), o incluso ``ficheros punto (dot files)'', porque
los nombres de los ficheros siempre empiezan con ``{\tt .}''.
Recordemos que los ficheros que empiezan por ``{\tt .}''  no se
visualizan normalmente con \cmdnm{ls}.

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

\subsection{Arranque del shell}

Hay diferentes modos de funcionamiento del \cmdnm{bash}.  Puede
funcionar como {\bf shell de ingreso}\index{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 \cmdnm{bash} es como {\bf shell
  interactivo}\index{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 \cmdnm{xterm}\ttindex{xterm}.  Cualquier shell que sea
creado por otro medio distinto del ingreso registrado en el sistema es
un shell de no-ingreso.

Finalmente, hay {\bf shells no interactivos}\index{shell no
  interactivo}.  Estos shells se usan para ejecutar un archivo de
comandos, muy parecidos a los ficheros de procesamiento por lotes del
MS-DOS \index{MS-DOS} ---los archivos que acaban en \file{.BAT}.
Estas {\bf macros de shell} \index{macro 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:

\begin{center}
\begin{tabular}{|l|l|}\hline
  \multicolumn{1}{|c|}{Tipo de Shell} &
     \multicolumn{1}{c|}{Acción}\\ \hline
  Ingreso interactivo & Se lee y ejecuta el archivo 
                        \file{.bash\_profile}. \\ \hline
  Interactivo         & Se lee y ejecuta el archivo 
                        \file{.bashrc}\ttindex{.bashrc}.\\ \hline
  No interactivo   & Se lee y ejecuta la macro de shell. \\ \hline
\end{tabular}
\end{center}

\subsection{Ficheros de arranque}

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 \file{.bash\_profile}:
\cmdln{source \char`\~/.bashrc}.  El comando
\cmdnm{source}\ttindex{source} ordena al shell que interprete el
argumento como una macro de shell.  Lo que significa para nosotros es
que cada vez que \cmdnm{.bash\_profile} se ejecuta, {\em también\/} se
ejecuta \cmdnm{.bashrc}.

Ahora, sólo añadiremos comandos a nuestro archivo \file{.bashrc}.  Si
alguna vez queremos que se ejecute un comando únicamente cuando hemos
hecho un ingreso registrado, lo añadiremos a nuestro
\file{.bash\_profile}.

\subsection{Creando alias}\label{aliasing-section}

¿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
\file{.bashrc}:

\begin{screen}\begin{verbatim}
alias ll="ls -l"
\end{verbatim}\end{screen}

Este comando define un {\bf alias}\impindex{shell!alias} de shell
llamado \cmdnm{ll} que ``expande'' el comando normal de shell
\cmdln{ls~-l} cuando se invoca por el usuario.  De modo que, asumiendo
que Bash ha leído este comando del fichero \file{.bashrc}, podemos
teclear \cmdnm{ll} para conseguir el efecto de \cmdln{ls~-l} con solo
la mitad de pulsaciones.  Lo que ocurre es que cuando tecleamos
\cmdln{ll} y pulsamos \key{Intro}, Bash lo intercepta, lo reemplaza
por \cmdln{ls~-l}, y ejecuta éste en su lugar.  No hay ningún programa
llamado \cmdnm{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~\ref{ejemplo-alias}.  Puede
ponerlos en su propio \file{.bashrc}.  Uno especialmente interesante
es el primero.  Con él, cada vez que alguien teclea \cmdln{ls},
automaticamente tiene una opción \cmdln{-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 \cmdln{\#} en la
figura~\ref{ejemplo-alias}.  Cada vez que aparece un \cmdln{\#}, el
shell ignora el resto de la línea.\index{shell!comentarios}

\begin{figure}\label{ejemplo-alias}
\begin{screen}\begin{verbatim}
alias ls="ls -F"          # muestra los caracteres al final del listado
alias ll="ls -l"          # ls especial
alias la="ls -a"
alias ro="rm *~; rm .*~"  # este borra las copias de seguridad creadas por Emacs
alias rd="rmdir"          # ahorra teclas!
alias md="mkdir"
alias pu=pushd            # pushd, popd, y dirs no estan incluidos en este
alias po=popd             # manual---quiza quiera echarles un vistazo
alias ds=dirs             # en la pagina man de Bash
# estos solo son atajos de teclado
alias to="telnet cs.oberlin.edu"
alias ta="telnet altair.mcs.anl.gov"
alias tg="telnet wombat.gnu.ai.mit.edu"
alias tko="tpalk kold@cs.oberlin.edu"
alias tjo="talk jimb@cs.oberlin.edu"
alias mroe="more"         # correcion ortografica!
alias moer="more"
alias email="emacs -f rmail" # mi lector de correo
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\"" # asi llamo a Emacs
\end{verbatim}\end{screen}
\caption{Algunos alias de ejemplo para \cmdnm{bash}.}
\end{figure}

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

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:

\begin{screen}\begin{verbatim}
alias rf="refrobnicate -verbose -prolix -wordy -o foo.out"
\end{verbatim}\end{screen}
    
Además, el último alias tiene algún entrecomillado gracioso:

\begin{screen}\begin{verbatim}
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\""
\end{verbatim}\end{screen}

Como es fácil suponer, he querido pasar entrecomillados dentro de las
opciones, así que tengo que anteponerles una contrabarra para que
\cmdnm{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,
\cmdnm{more}.  Los alias no interfieren con el paso de argumentos a un
programa.  Lo siguiente funciona bien:

\begin{screen}\begin{verbatim}
/home/larry$ mroe hurd.txt
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs
    
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.

\subsection{Variables de entorno}\label{section-env-variables}

Otra cosa que uno hace frecuentemente en \file{.bashrc} es definir
{\bf variables de entorno}\index{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
\cmdnm{fruggle}, y se encuentra con una de estas expresiones:

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

Cada programa se ejecuta en un {\bf entorno}\index{entorno}, y ese
entorno es definido por el shell que llamó al programa\footnote{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!}.  Se puede decir que el entorno existe ``dentro'' del
shell.  Los programadores tienen una rutina especial para interrogar
al entorno, y el programa \cmdnm{fruggle} usa esa rutina.  Comprueba
el valor de la variable de entorno {\tt FRUGGLEPATH}.  Si esa variable
no está definida, sencillamente usará el archivo \file{.frugglerc} del
directorio raíz. Si está definida, usará el valor de esa variable (que
debe ser el nombre de un archivo que \cmdnm{fruggle} pueda usar) en
lugar del archivo por defecto \file{.frugglerc}.

Así es como se puede cambiar el entorno en \cmdnm{bash}\ttindex{bash}:

\begin{screen}\begin{verbatim}
/home/larry$ export PGPPATH=/home/larry/secrets/pgp
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

Hay que pensar en el comando \cmdnm{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 \cmdnm{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\index{Zimmerman,
  Paul}, \cmdnm{pgp}\ttindex{pgp}.  Por defecto, \cmdnm{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 {\tt PGPPATH}, le he dicho que use el
directorio \file{/home/larry/secrets/pgp} en lugar de
\file{/home/larry}.  He tenido que leer el manual de \cmdnm{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:

\begin{screen}\begin{verbatim}
/home/larry$ echo $PGPPATH
/home/larry/.pgp
/home/larry$
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

Nótese el \cmdln{\$}; 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, \cmdnm{echo} simplemente habría mostrado su(s)
argumento(s):

\begin{screen}
   \begin{verbatim}
/home/larry$ echo PGPPATH
PGPPATH
/home/larry$
   \end{verbatim}
\end{screen}

El \cmdln{\$} se usa para {\em 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 \cmdnm{bash} está
leyendo comandos de un archivo como \file{.bashrc}, se puede decir que
está ``interpretando'' los comandos.

Hay otro comando muy útil para preguntar al entorno:
\cmdnm{env}''\impttindex{env}.  \cmdnm{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 \cmdnm{env} a través de \cmdnm{more}: \cmdln{env | more}.

Unas cuantas de estas variables pueden ser muy útiles, así que las
comentaremos.  Mire la Figura~\ref{env-variables}.  Estas cuatro
variables están definidas automáticamente cuando se ingresa en el
sistema: no se definen en \file{.bashrc} o \file{.bash\_login}.

\begin{figure}\label{env-variables}
\begin{center}
\begin{tabular}{|l|l|l|}\hline
  \multicolumn{1}{|c|}{Nombre} &
    \multicolumn{1}{c|}{Contenido} &
    \multicolumn{1}{c|}{Ejemplo}\\ \hline
  {\tt HOME} & Directorio principal del usuario & \file{/home/larry} \\ \hline
  {\tt TERM} & Tipo de terminal del usuario & 
               {\tt xterm}, {\tt vt100}, o {\tt console} \\ \hline
  {\tt SHELL} & Path del shell del usuario & \file{/bin/bash} \\ \hline
  {\tt USER} & Nombre de ingreso & {\tt larry} \\ \hline
  {\tt PATH} & Lista de búsqueda de programas &
    \file{/bin:/usr/bin:/usr/local/bin:/usr/bin/X11}\\ \hline
\end{tabular}
\end{center}
\caption{Algunas variables de entorno importantes.}
\end{figure}

Vamos a echar un vistazo más de cerca a la variable {\tt
  TERM}\index{terminales}.  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
carácteres 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 ¿como podían emplear
nuevas características sin convertir los viejos terminales en
inservibles?

En \unix, la respuesta a estas cuestiones fue \file{/etc/termcap}
\ttindex{/etc/termcap}.  \file{/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
\file{/etc/termcap} en lugar de recompilar todo el \unix.  A veces es
incluso más simple.  Al pasar el tiempo, el {\tt vt100}\index{vt100}
de Digital Equipment Corporation\index{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 {\tt vt100}.

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

\bindex{shell!path de busqueda}

Otra variable, {\tt PATH}, es tambien crucial para el funcionamiento
correcto del shell. Aquí está la mía:

\begin{screen}\begin{verbatim}
/home/larry$ env | grep ^PATH
PATH=/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
/home/larry$
\end{verbatim}\end{screen}

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

\begin{screen}\begin{verbatim}
/home/larry$ /usr/bin/ls
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

La variable {\tt 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 {\tt PATH}, en orden,
y si lo encuentra, lo ejecuta.  Si no lo encuentra, devuelve un
descortés mensaje de error:

\begin{screen}\begin{verbatim}
/home/larry$ clubly
clubly: command not found
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs
    
Notar que en mi {\tt PATH} no existe el directorio actual, ``{\tt
  .}''.  Si estuviera, tendría este aspecto:

\begin{screen}\begin{verbatim}
/home/larry$ echo $PATH
.:/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
/home/larry$
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

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 \file{ls}, y hacemos un \cmdnm{ls}, como es natural
después de entrar en un directorio nuevo.  Como el directorio actual,
``{\tt .}'', viene primero en nuestro {\tt PATH}, el shell encontrará
esta versión de \cmdnm{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'' \cmdnm{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 ``{\tt .}'' 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ícitos\footnote{Recuérdese que siempre se
  puede ejecutar un programa en el directorio actual siendo explícito,
  p.ej.: \cmdln{./foo}''\,.}.  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 {\tt 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 \file{.bashrc}:

\begin{screen}\begin{verbatim}
export PATH=${PATH}:.:${HOME}/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin
\end{verbatim}\end{screen}

\eindex{shell!path de búsqueda}

Me aprovecho de que la variable {\tt HOME} se activa antes de que Bash
lea el fichero \file{.bashrc}, usando su valor en la construcción del
{\tt PATH}.  Las llaves (``{\tt \{\ldots\}}'') 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
(``{\tt /bin}'' en este caso).  Aquí hay otro ejemplo del efecto que
tienen:

\begin{screen}\begin{verbatim}
/home/larry$ echo ${HOME}foo
/home/larryfoo
/home/larry$
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

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

\begin{screen}\begin{verbatim}
/home/larry$ echo $HOMEfoo

/home/larry$
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

Quisiera aclarar una cosa en este path: el significado de ``{\tt
  \${PATH}}''.  Lo que hace es incluir el valor de cualquier variable
{\tt PATH} {\em previamente\/} activada en mi nuevo {\tt PATH}.
¿Dónde se habrá activado la variable anterior?  El archivo
\file{/etc/profile} sirve como una especie de \file{.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 {\tt 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 {\bf PS1}.  Personalmente, quiero un
prompt que me indique el path del directorio actual---así es
\char`\"como lo hago en mi \file{.bashrc}:

\begin{screen}\begin{verbatim}
export PS1='$PWD\$ '
\end{verbatim}\end{screen}
% $ para equilibrar el font-lock-mode de emacs

\bindex{shell!literales}

Como se puede ver, en realidad se usan {\em dos\/} variables.  La que
se activa es {\tt PS1}, y toma el valor de {\tt 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 {\tt 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 {\tt PWD}.  Si
sólo hubieramos hecho \cmdln{export~PS1=\$PWD}, nuestro prompt nos
habría mostrado constantemente el path del directorio de trabajo {\em
  en el momento en que\/} {\tt PS1} {\em fué 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 \cmdln{export PS1='{}\$PWD>'{}}, o incluso el nombre
del sistema:

\begin{screen}\begin{verbatim}
export PS1=`hostname`'>'
\end{verbatim}\end{screen}

Diseccionemos este ejemplo un poco más.  Aquí se usa un {\em nuevo\/}
tipo de literal, el apóstrofo grave.  Esta clase de literal no protege
nada ---de hecho, {\tt '{}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 \cmdln{echo `ls`} o \cmdln{wc `ls`}.  A medida que se
consiga más experiencia usando el shell, esta técnica se hace más y
más potente.

\eindex{shell!literales}

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

\begin{screen}\begin{verbatim}
# Algunas cosas al azar:
ulimit -c unlimited
export history_control=ignoredups
export PS1='$PWD>'
umask 022

# paths específicos de aplicaciones:
export MANPATH=/usr/local/man:/usr/man
export INFOPATH=/usr/local/info
export PGPPATH=${HOME}/.pgp

# PATH principal:
homepath=${HOME}:~/bin
stdpath=/bin:/usr/bin:/usr/local/bin:/usr/ucb/:/etc:/usr/etc:/usr/games
pubpath=/usr/public/bin:/usr/gnusoft/bin:/usr/local/contribs/bin
softpath=/usr/bin/X11:/usr/local/bin/X11:/usr/TeX/bin
export PATH=.:${homepath}:${stdpath}:${pubpath}:${softpath}
# Técnicamente, las llaves no eran necesarias, porque los dos puntos son
# delimitadores válidos; pero las llaves son una buena costumbre, 
# y no hacen daño.

# alias
alias ls="ls -CF"
alias fg1="fg %1"
alias fg2="fg %2"
alias tba="talk sussman@tern.mcs.anl.gov"
alias tko="talk kold@cs.oberlin.edu"
alias tji="talk jimb@totoro.bio.indiana.edu"
alias mroe="more"
alias moer="more"
alias email="emacs -f vm"
alias pu=pushd
alias po=popd
alias b="~/.b"
alias ds=dirs
alias ro="rm *~; rm .*~"
alias rd="rmdir"
alias ll="ls -l"
alias la="ls -a"
alias rr="rm -r"
alias md="mkdir"
alias ed2="emacs -d floss:0 -fg \"grey95\" -bg \"grey50\""

function gco
{
  gcc -o $1 $1.c -g
}
\end{verbatim}\end{screen}

% $ <- para confundir el resaltado de emacs

\section{Los ficheros de inicio de X Window}

\xwarn 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\index{Macintosh} o al Microsoft
Windows\index{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 {\em
  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 espero\footnote{N. del
  T.: Yo también {\tt ;-)}}), 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:

\begin{samepage}
\begin{tabular}{ll}
\file{.xinitrc} & Un script arrancado por~X cuando se inicia. \\
\file{.twmrc}   & Leido por el gestor de X~Window, \cmdnm{twm}\ttindex{twm}. \\
\file{.fvwmrc}  & Leido por el gestor de X~Window, \cmdnm{fvwm}\ttindex{fvwm}. \\
\end{tabular}
\end{samepage}
        
Todos estos ficheros deberían estar en el directorio {\tt \$HOME}, si
es que existen.

\file{.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 \file{.xinitrc} es usualmente el nombre de un
gestor de ventanas a ejecutar, por ejemplo \cmdnm{/usr/bin/X11/twm}.

¿Qué tipo de cosas nos gustaría poner en \file{.xinitrc}?  Quizá
algunas llamadas al programa \cmdnm{xsetroot}, para hacer que la
ventana de fondo (escritorio) y el ratón tengan el aspecto que
deseamos.  Llamadas a \cmdnm{xmodmap}, que informa al
servidor\footnote{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''.}  de como interpretar las señales del teclado.
O cualquier otro programa que se quiera iniciar cada vez que se
arranque~X (por ejemplo, \cmdnm{xclock}).

Aquí está una parte de mi \file{.xinitrc}; el suyo seguramente será
distinto, así que hay que tomárselo sólo como ejemplo:

\begin{screen}\begin{verbatim}
#!/bin/sh
# La primera línea le dice al sistema operativo que shell usar para
# interpretar esta macro. La macro en sí misma debe estar marcada como 
# ejecutable; se puede hacer con "chmod +x ~/.xinitrc".

# xmodmap es un programa que informa al servidor X de como interpretar las
# señales del teclado. Es *definitivamente* aconsejable aprender como
# funciona. Se puede probar con "man xmodmap", "xmodmap -help", 
# "xmodmap -grammar", y otras opciones.
# No garantizo que las expresiones abajo escritas signifiquen nada en tu 
# sistema (ni siquiera garantizo que signifiquen algo en el mío):
xmodmap -e 'clear Lock'
xmodmap -e 'keycode 176 = Control_R'
xmodmap -e 'add control = Control_R'
xmodmap -e 'clear Mod2'
xmodmap -e 'add Mod1 = Alt_L Alt_R'

# xset es un programa para establecer otros parámetros del servidor X:
xset m 3 2 &       # parámetros del ratón
xset s 600 5 &     # preferencias del salvapantallas
xset s noblank &   # lo mismo
xset fp+ /home/larry/x/fonts # para cxterm
# Para aprender más, "xset -help".

# Ordena al servidor X que sobreponga fish.cursor sobre fish.mask, y use
# el patrón resultante como cursor del ratón:
xsetroot -cursor /home/lab/larry/x/fish.cursor /home/lab/larry/x/fish.mask &

# Un placentero patrón y color de fondo:
xsetroot -bitmap /home/lab/larry/x/pyramid.xbm -bg tan

# para hacer: xrdb aquí?  Y que hay del fichero .Xdefaults?

# Hay que mirar "man xsetroot", o "xsetroot -help" para más
# información sobre el programa usado arriba. 

# Un programa cliente, el imponente reloj circular de color de Jim Blandy:
/usr/local/bin/circles &

# Quizá os gustaría tener un reloj en la pantalla a todas horas?
/usr/bin/X11/xclock -digital &

# Permite a programas cliente de X ejecutándose en occs.cs.oberlin.edu 
# mostrarse a sí mismos aquí, y lo mismo para juju.mcs.anl.gov:
xhost occs.cs.oberlin.edu
xhost juju.mcs.anl.gov

# Se puede simplemente decirle al servidor X que permita usar aquí
# a clientes que estén ejecutándose en cualquier otra máquina, 
# pero esto es un agujero en la seguridad -- ¡estos clientes pueden ser
# usados por cualquier otro, que puede vigilar lo que se teclea cuando se
# entra una contraseña, o algo así!
# Si se quiere hacerlo de todos modos, se puede usar un "+" para indicar 
# cualquier nombre de host posible, en lugar de un nombre específico, 
# así:
# xhost +

# Y finalmente arrancar el gestor de ventanas:
/usr/bin/X11/twm
# Alguna gente prefiere otros gestores de ventanas.  Yo uso twm, pero fvwm se
# distribuye también muchas veces con Linux:
# /usr/bin/X11/fvwm
\end{verbatim}\end{screen}

% [Larry, o cualquiera, tiene importancia si el gestor de ventanas
% arranca de fondo o no ? Parece funcionar bien de las dos maneras; me 
% pregunto si tiene importancia recomendar un ``\&'' o no.-Karl] 
% Creo que es preferible sin ``&'', para que el servidor finalice al mismo 
% tiempo que el gestor de ventanas

Nótese que algunos comandos son iniciados en segundo plano (p.ej.:
los que van seguidos de ``{\tt \&}''), 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.
\cmdnm{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 \cmdnm{twm}, el fichero es \file{.twmrc} en nuestro
directorio home.  Si se usa \cmdnm{fvwm}, el fichero es
\file{.fvwmrc}, etc.  Explicaremos sólo estos dos, ya que son los
gestores de ventanas que más frecuentemente se encontrarán con
Linux.

\subsection{Configuración de twm}\label{twm-config-section}

\bttindex{twm}

\file{.twmrc} no es una macro de shell---está escrito en un
lenguaje especialmente hecho para \cmdnm{twm}, ¡créalo o
no!\footnote{É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.}  Principalmente, a la gente en su
\file{.twmrc} le gusta jugar con los estilos de la ventana (colores y
demás), y hacer interesantes menús, así que ahí va
un \file{.twmrc} de ejemplo:

\begin{screen}
    \begin{verbatim}
# Indica colores para varias partes de una ventanas. Tiene un gran impacto
# en la "sensación" que transmite el entorno.
Color
{
    BorderColor "OrangeRed"
    BorderTileForeground "Black"
    BorderTileBackground "Black"
    TitleForeground "black"
    TitleBackground "gold"
    MenuForeground "black"
    MenuBackground "LightGrey"
    MenuTitleForeground "LightGrey"
    MenuTitleBackground "LightSlateGrey"
    MenuShadowColor "black"
    IconForeground "DimGray"
    IconBackground "Gold"
    IconBorderColor "OrangeRed"
    IconManagerForeground "black"
    IconManagerBackground "honeydew"
}

# Espero que no tengas un sistema monocromo, pero si lo tienes...
Monochrome
{
    BorderColor "black"
    BorderTileForeground "black"
    BorderTileBackground "white"
    TitleForeground "black"
    TitleBackground "white"
}

# He creado beifang.bmp con el programa "bitmap". Aquí le digo a twm 
# que lo use como el patrón por defecto para destacar las barras de 
# título de las ventanas:
Pixmaps
{
    TitleHighlight "/home/larry/x/beifang.bmp"
}

# No os preocupéis por estas cosas, son sólo para usuarios avanzados :-)
BorderWidth     2
TitleFont       "-adobe-new century schoolbook-bold-r-normal--14-140-75-75-p-87-iso8859-1"
MenuFont        "6x13"
IconFont        "lucidasans-italic-14"
ResizeFont      "fixed"
Zoom 50
RandomPlacement

# Estos programas no tendrán una barra de título por defecto
NoTitle
{
  "stamp"
  "xload"
  "xclock"
  "xlogo"
  "xbiff"
  "xeyes"
  "oclock"
  "xoid"
}

# "AutoRaise" significa que una ventana aparece al frente cuando el ratón
# entra en ella. Lo encuentro desconcertante, así que lo he desactivado.
# Como puedes ver, he heredado mi .twmrc de otra gente a quien tampoco le
# gustaba Autoraise.
AutoRaise 
{
  "nothing"     # No me gusta auto-raise  # Ni a mi  # A mi tampoco
}

# Aquí es donde se define la función de los botones del mouse. 
# Nótese el patrón: Un botón del ratón pulsado en la ventana
# principal, si no se está pulsando ninguna tecla modificadora, siempre
# hace aparecer un menú.  Otras posiciones usualmente producen 
# modificaciones de la ventana en algún modo, y las teclas modificadoras
# se usan junto con los botones del ratón para acceder a las funciones
# más avanzadas de manipulación de ventanas.
#
# No hay porqué seguir este patrón en .twmrc -- el cómo 
# establecer el entorno es un asunto totalmente personal

# Button = KEYS : CONTEXT : FUNCTION
# ----------------------------------
Button1 =      : root    : f.menu "main"
Button1 =      : title   : f.raise
Button1 =      : frame   : f.raise
Button1 =      : icon    : f.iconify
Button1 = m    : window  : f.iconify

Button2 =      : root    : f.menu "stuff"
Button2 =      : icon    : f.move
Button2 = m    : window  : f.move
Button2 =      : title   : f.move
Button2 =      : frame   : f.move
Button2 = s    : frame   : f.zoom
Button2 = s    : window  : f.zoom

Button3 =      : root    : f.menu "x"
Button3 =      : title   : f.lower
Button3 =      : frame   : f.lower
Button3 =      : icon    : f.raiselower

# Puedes escribir tus propias funciones; esta se usa en el menú
# "windowops" cerca del final de este fichero:
Function "raise-n-focus"
{
    f.raise
    f.focus
}

# Muy bien, abajo están los menús a los que me refería en la
# sección de los botones del ratón.  Nótese que muchas de estas
# entradas de menú llaman a submenús a su vez.  Se pueden tener tantos
# niveles como se quiera, pero no se pueden tener menús recursivos.  Ya
# lo he probado.

menu "main"
{
"Vanilla"       f.title
"Emacs"         f.menu "emacs"
"Logins"        f.menu "logins"
"Xlock"         f.menu "xlock"
"Misc"          f.menu "misc"
}

# Esto me permite llamar a emacs desde varias máquinas diferentes.  Ver
# la sección sobre ficheros .rhosts para más información sobre
# como funciona:
menu "emacs"
{
"Emacs"      f.title
"here"       !"/usr/bin/emacs &"
""           f.nop
"phylo"      !"rsh phylo \"emacs -d floss:0\" &"
"geta"       !"rsh geta \"emacs -d floss:0\" &"
"darwin"     !"rsh darwin \"emacs -d floss:0\" &"
"ninja"      !"rsh ninja \"emacs -d floss:0\" &"
"indy"       !"rsh indy \"emacs -d floss:0\" &"
"oberlin"    !"rsh cs.oberlin.edu \"emacs -d floss.life.uiuc.edu:0\" &"
"gnu"        !"rsh gate-1.gnu.ai.mit.edu \"emacs -d floss.life.uiuc.edu:0\" &"
}

# Esto me permite llamar a xterms desde varias máquinas diferentes.  Ver
# la sección sobre ficheros .rhosts para más información sobre
# como funciona:
menu "logins"
{
"Logins"     f.title
"here"       !"/usr/bin/X11/xterm -ls -T `hostname` -n `hostname` &"
"phylo"      !"rsh phylo \"xterm -ls -display floss:0 -T phylo\" &"
"geta"       !"rsh geta \"xterm -ls -display floss:0 -T geta\" &"
"darwin"     !"rsh darwin \"xterm -ls -display floss:0 -T darwin\" &"
"ninja"      !"rsh ninja \"xterm -ls -display floss:0 -T ninja\" &"
"indy"       !"rsh indy \"xterm -ls -display floss:0 -T indy\" &"
}

# El salvapantallas xlock, llamado con varias opciones (cada una de 
# ellas da una bonita imagen):
menu "xlock"
{
"Hop"   !"xlock -mode hop &"
"Qix"   !"xlock -mode qix &"
"Flame" !"xlock -mode flame &"
"Worm" !"xlock -mode worm &"
"Swarm" !"xlock -mode swarm &"
"Hop NL"   !"xlock -mode hop -nolock &"
"Qix NL"   !"xlock -mode qix -nolock &"
"Flame NL" !"xlock -mode flame -nolock &"
"Worm NL" !"xlock -mode worm -nolock &"
"Swarm NL" !"xlock -mode swarm -nolock &"
}

# Programas de todo tipo que uso ocasionalmente:
menu "misc"
{
"Xload"         !"/usr/bin/X11/xload &"
"XV"            !"/usr/bin/X11/xv &"
"Bitmap"        !"/usr/bin/X11/bitmap &"
"Tetris"        !"/usr/bin/X11/xtetris &"
"Hextris"       !"/usr/bin/X11/xhextris &"
"XRoach"        !"/usr/bin/X11/xroach &"
"Analog Clock"  !"/usr/bin/X11/xclock -analog &"
"Digital Clock" !"/usr/bin/X11/xclock -digital &"
}

# Esto es para lo que uso el botón central del ratón:
menu "stuff"
{
"Chores"       f.title
"Sync"         !"/bin/sync"
"Who"          !"who | xmessage -file - -columns 80 -lines 24 &"
"Xhost +"      !"/usr/bin/X11/xhost + &"
"Rootclear"    !"/home/larry/bin/rootclear &"
}

# Funciones de X que a veces conviene usar:
menu "x"
{
"X Stuff"               f.title
"Xhost +"               !"xhost + &"
"Refresh"               f.refresh
"Source .twmrc"         f.twmrc
"(De)Iconify"           f.iconify
"Move Window"           f.move
"Resize Window"         f.resize
"Destroy Window"        f.destroy
"Window Ops"            f.menu "windowops"
""                      f.nop
"Kill twm"              f.quit
}

# Este es un submenú del de arriba:
menu "windowops"
{
"Window Ops"            f.title
"Show Icon Mgr"         f.showiconmgr
"Hide Icon Mgr"         f.hideiconmgr
"Refresh"               f.refresh
"Refresh Window"        f.winrefresh
"twm version"           f.version
"Focus on Root"         f.unfocus
"Source .twmrc"         f.twmrc
"Cut File"              f.cutfile
"(De)Iconify"           f.iconify
"DeIconify"             f.deiconify
"Move Window"           f.move
"ForceMove Window"      f.forcemove
"Resize Window"         f.resize
"Raise Window"          f.raise
"Lower Window"          f.lower
"Raise or Lower"        f.raiselower
"Focus on Window"       f.focus
"Raise-n-Focus"         f.function "raise-n-focus"
"Destroy Window"        f.destroy
"Kill twm"              f.quit
}
    \end{verbatim}
\end{screen}

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

Un defecto de programa que hay que vigilar en los ficheros
\file{.twmrc} es no olvidarse de poner el ``{\tt \&}'' 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 \key{Ctrl}-\key{Alt}-\key{Retroceso}, editar
\file{.twmrc}, y probar otra vez\ettindex{twm}.

\subsection{Configuración de fvwm}\label{fvwm-config-section}
\bttindex{fvwm}

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

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

\section{Otros ficheros de inicio}

Otros ficheros de inicio dignos de mención son:

\begin{samepage}
\begin{tabular}{ll}
\file{.emacs}    & Leido por el editor de texto Emacs cuando arranca. \\
\file{.netrc}    & Da los nombres y contraseñas por defecto para ftp. \\
\file{.rhosts}   & Hace una cuenta accesible remotamente. \\
\file{.forward}  & Para redirección automática del correo. \\
\end{tabular}
\end{samepage}

\subsection{El fichero de configuración de Emacs}

Si se usa \cmdnm{emacs} como editor principal, entonces el fichero
\file{.emacs} es muy importante.  Se discute con extensión en el
Capítulo~\ref{emacs-chapter}.

\subsection{Configuración por defecto del FTP}

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

  \begin{screen}
    \begin{verbatim}
machine floss.life.uiuc.edu login larry password fishSticks
machine darwin.life.uiuc.edu login larry password fishSticks
machine geta.life.uiuc.edu login larry password fishSticks
machine phylo.life.uiuc.edu login larry password fishSticks
machine ninja.life.uiuc.edu login larry password fishSticks
machine indy.life.uiuc.edu login larry password fishSticks

machine clone.mcs.anl.gov login fogel password doorm@
machine osprey.mcs.anl.gov login fogel password doorm@
machine tern.mcs.anl.gov login fogel password doorm@
machine altair.mcs.anl.gov login fogel password doorm@
machine dalek.mcs.anl.gov login fogel password doorm@
machine juju.mcs.anl.gov login fogel password doorm@

machine sunsite.unc.edu login anonymous password larry@cs.oberlin.edu
    \end{verbatim}
  \end{screen}

Cada línea de \file{.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 \cmdnm{ftp}
continuamente y se está harto de teclear el nombre de acceso y la
contraseña en cada uno.  El programa de \cmdnm{ftp} intentará
acceder automáticamente usando los datos del fichero \file{.netrc},
si se hace \cmdnm{ftp} a una de las máquinas listadas allí.

Se puede obligar a \cmdnm{ftp} a ignorar el fichero \file{.netrc} y no
intentar acceder de manera automática, arrancándolo con la
opción \cmdln{-n}: \cmdln{ftp~-n}.

Hay que asegurarse de que el fichero \file{.netrc} {\em sólo\/} es
legible por el usuario.  Se puede usar el programa \cmdnm{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,
\cmdnm{ftp} y otros programas que miran el fichero \file{.netrc} no
funcionarán si los permisos de lectura del fichero son
incorrectos.

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

\subsection{Permitiendo un acceso remoto sencillo a su cuenta}

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

El archivo \file{.rhosts} se ve más o menos así:

  \begin{screen}
    \begin{verbatim}
frobnozz.cs.knowledge.edu jsmith
aphrodite.classics.hahvaahd.edu wphilps
frobbo.hoola.com trixie
    \end{verbatim}
  \end{screen}

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 \file{.rhosts} en {\tt floss.life.uiuc.edu}.  Esto
significaría que puedo usar programas en {\tt 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 \cmdnm{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:

\begin{screen}\begin{verbatim}
frobbo$ whoami
trixie
frobbo$ rsh floss.life.uiuc.edu "ls ~"
foo.txt    mbox   url.ps    snax.txt
frobbo$ rsh floss.life.uiuc.edu "more ~/snax.txt"
  [snax.txt aparece pagina a pagina aqui]
\end{verbatim}\end{screen}

% $

El usuario ``{\tt trixie}'' en ``{\tt floss.life.uiuc.edu}'', que
tenía el fichero \file{.rhosts} de ejemplo mostrado antes,
permite explicitamente a ``{\tt trixie}'' en ``{\tt
frobbo.hoola.com}'' usar programas como si fuera ``{\tt trixie}'' de
``{\tt floss}''.

No hay porqué tener el mismo nombre de usuario en todas las
máquinas para que \file{.rhosts} funcione.  Se puede usar la
opción \cmdln{-l} con \cmdnm{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 \file{.rhosts} con el nombre de la máquina local y el
nombre de usuario correspondiente, entonces la orden incluída con
\cmdnm{rsh} se ejecutará.

\begin{screen}\begin{verbatim}
frobbo$ whoami
trixie
frobbo$ rsh -l larry floss.life.uiuc.edu "ls ~"
[Inserta aqui un listado de mi directorio en floss]
\end{verbatim}\end{screen}

Esto funcionará si el usuario ``{\tt larry}'' en ``{\tt
floss.life.uiuc.edu}'' tiene un fichero \file{.rhosts} que permite a
``{\tt trixie}'' de ``{\tt 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 ``{\tt floss}'' en el
\file{.rhosts} de Larry.  Nótese que el fichero \file{.rhosts} de
Trixie en {\tt frobbo} no importa, sólo cuenta el de la máquina
remota.

Hay otras combinaciones que se pueden poner en un fichero
\file{.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 \file{.rhosts} es legible sólo por el
usuario implicado, y por nadie más.

\subsection{Redirección de correo}

También se puede tener un fichero \file{.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 \file{\$HOME} que empiecen por ``{\tt .}''.
No es seguro que todos sean ficheros de configuración, pero seguro
que la mayoría sí lo es.

\section{Veamos algunos ejemplos}

% Heh heh, creeis que es un gran error ? Me arriesgaré por ahora...

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 \cmdnm{telnet} a {\tt 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
\file{/home/kfogel}, pero también hay otros directorios de
usuarios.  Sois libres de copiar cualquier cosa que se pueda leer.
Por favor tened cuidado: {\tt 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.

% Local Variables: 
% mode: latex
% TeX-master: "guide"
% End: 
