Capítulo 9


 

¡Tengo que ser yo mismo!

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

 

9.1 Personalización del 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 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.

 

9.1.1 Arranque del shell

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:

Tipo de Shell

Acción

Ingreso interactivo

Se lee y ejecuta el archivo .bash_profile

Interactivo

Se lee y ejecuta el archivo .bashrc

No_interactivo

Se lee y ejecuta la macro de shell

 

9.1.2 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 .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.

 

9.1.3 Creando alias

¿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:

alias ll="ls -l"

 

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.

Alias

Comentario

alias ls="ls -F"

alias ll="ls -l"

alias la="ls -a"

alias ro="rm *~; rm .*~"

alias rd="rmdir"

alias md="mkdir"

alias pu=pushd

alias po=popd

alias ds=dirs

# muestra los caracteres al final del listado

# ls especial

 

# este borra las copias de seguridad creadas por Emacs

# ahorra teclas!

 

# pushd, popd, y dirs no estan incluidos en este

# manual---quiza quiera echarles un vistazo

# en la pagina man de Bash

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"

alias moer="more"

alias email="emacs -f rmail"

alias ed2="emacs -d floss:0 -fg ""grey95"" -bg ""grey50"""

# estos solo son atajos de teclado

 

 

 

 

# correcion ortografica!

 

# mi lector de correo

# asi llamo a Emacs

 

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:

alias rf="refrobnicate -verbose -prolix -wordy -o foo.out"

 

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

alias ed2="emacs -d floss:0 -fg ""grey95"" -bg ""grey50"""

 

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:

/home/larry$ mroe hurd.txt

 

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.

 

9.1.4 Variables de entorno

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:

/home/larry$ export PGPPATH=/home/larry/secrets/pgp

 

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:

/home/larry$ echo $PGPPATH

/home/larry/.pgp

/home/larry$

 

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):

/home/larry$ echo PGPPATH

PGPPATH

/home/larry$

 

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.

Nombre

Contenido

Ejemplo

HOME

Directorio principal del usuario

/home/larry

TERM

Tipo de terminal del usuario

xterm, vt100, o console

SHELL

Path del shell del usuario

/bin/bash

USER

Nombre de ingreso

larry

PATH

Lista de búsqueda de programas

/bin:/usr/bin:/usr/local/bin:/usr/bin/X11

 

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:

/home/larry$ env _ grep ^PATH

PATH=/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin

/home/larry$

 

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:

/home/larry$ /usr/bin/ls

 

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:

/home/larry$ clubly

clubly: command not found

 

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

/home/larry$ echo $PATH

.:/home/larry/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/TeX/bin

/home/larry$

 

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:

/home/larry$ echo $-HOME"foo

/home/larryfoo

/home/larry$

 

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

/home/larry$ echo $HOMEfoo

 

/home/larry$

 

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:

export PS1='$PWD"$ '

 

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:

export PS1=`hostname`'>'

 

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.

# 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

"

 

 

9.2 Los ficheros de inicio de X Window

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:

.xinitrc Un script arrancado por X cuando se inicia.

.twmrc Leido por el gestor de X Window, twm.

.fvwmrc Leido por el gestor de X Window, fvwm.

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:

#!/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

 

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.

 

9.2.1 Configuración de twm

.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:

# 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

"

 

_____________________________________________

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.

 

9.2.2 Configuración de fvwm

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]

 

9.3 Otros ficheros de inicio

Otros ficheros de inicio dignos de mención son:

.emacs Leído por el editor de texto Emacs cuando arranca.

.netrc Da los nombres y contraseñas por defecto para ftp.

.rhosts Hace una cuenta accesible remotamente.

.forward Para redirección automática del correo.

 

9.3.1 El fichero de configuración de Emacs

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

 

9.3.2 Configuración por defecto del FTP

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

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

 

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".

 

9.3.3 Permitiendo un acceso remoto sencillo a su cuenta

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í:

frobnozz.cs.knowledge.edu jsmith

aphrodite.classics.hahvaahd.edu wphilps

frobbo.hoola.com trixie

 

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:

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]

 

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á.

frobbo$ whoami

trixie

frobbo$ rsh -l larry floss.life.uiuc.edu "ls ~"

[Inserta aqui un listado de mi directorio en floss]

 

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.

 

9.3.4 Redirección de correo

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.

 

9.4 Veamos algunos ejemplos

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.