Todo lo que se necesita para empezar a investigar y para despertar tu
interés (si a estas alturas la programación en shell no ha
despertado tu interés, dudo que lo haga) ya se ha visto. Lo único
que queda son decir algunas cosas más, y decir que si crees que le falta
algo de potencia, que te mires algún libro. Hay algunas cosas que yo no
he querido poner en este documento, como por ejemplo atrapar las señales
del sistema, una orden para manejar los parámetros estilo UNIX (es
decir, con - al principio, y pudiendo agrupar -l -F en
-lF), y otras cosas.
En los programas muchas veces es útil consultar las
variables de entorno. Por ejemplo, el usuario puede tener definido su editor
preferido enla variable $EDITOR. Así, si necesitamos editar un
texto, podemos llamar al editor que ponga la variable $EDITOR, en vez
de coger el que a nosotros nos dé la gana (ya se sabe, la guerra santa
vi-emacs, en la que por cierto soy defensor del vi,
hace estragos). Algunas variables útiles de entorno son:
Variable Significado
$PS1 Aspecto del apuntador (prompt) principal
$PS2 Aspecto del apuntador (prompt) secundario
$PWD Directorio actual
$HOME Directorio home del usuario que ejecuta el proceso
$USER Nombre de login del usuario que ejecuta el proceso
$$ PID del proceso
$PATH Ruta de búsqueda del usuario actual
El apuntador, como probablemente sabes, es lo que sale a la izquierda de la pantalla cuando escribes cosas. En una terminal UNIX, probablemente sea `$' en Linux seguramente es algo más complicado.
A lo mejor lo que no sabes es qué diablos es el apuntador secundario. Cuando escribes comillas (de cualquier tipo) en la línea de órdenes, pero pulsas Enter antes de terminar de escribir lo que tenías entre comillas (es decir, si abres comillas pero no las cierras), el intérprete enseñará el apuntador secundario en la siguiente línea, y seguirá poniendo apuntadores secundarios en las líneas subsiguientes hasta que cierres las comillas.
El PID de un proceso es su process id. Es un número
que sirve para identificar al proceso (cuando haces un kill y
similares). Este número es evidentemente único para cada
proceso, y lo podemos utilizar para crear ficheros en el directorio
/tmp únicos para esa interpretación del guión.
Piensa que si tuviéramos a dos usuarios diferentes ejecutando el mismo
guión a la vez, uno de ellos machacaría algún
hipotético fichero temporal que pudiera tener el primero, y se
formaría un pollo que no veas.
Algo a tener en cuenta cuando estemos programando apoyándonos en
variables de entorno, es que estas variables no se pueden modificar.
Podemos asignarles valores y cambiarán, pero sólo en nuestro
programa. Hay que tener en cuenta que $PWD, que es la variable que controla el
directorio actual, no tiene nada que ver con el núcleo del sistema
operativo, es un problema exclusivo del intérprete, que es al fin y al
cabo la interfaz para que el usuario se comunique con el sistema operativo.
Así, si escribimos un guión que cambie el directorio actual,
aunque sea mediante la orden cd, al salir del guión del
intérprete ni se habrá enterado.
El hecho de que nosotros modifiquemos una copia de las variables es por el hecho de que los guiones se ejecutan en otro intérprete diferente al actual, y entonces las variables de entorno simplemente se copian. Para que se copien, debemos exportar las variables. Todas las variables normales ya están exportadas en el fichero de configuración (ya sea en el general o en el de cada usuario), pero quizás algunas variables inventadas por nosotros o poco comunes queremos que sean exportadas también, para que cualquier otro programa pueda acceder a ellas para consultarlas.
La manera de forzar esto es con la orden export. La sintaxis
es, simplemente, export variable. Por ejemplo, export
EDITOR.
Pero nosotros hablábamos de ejecutar programas en el
intérprete actual, entre otras cosas para poder modificar variables de
entorno. La forma de hacer esto, es poner un punto (.) antes del nombre del
programa. Por ejemplo, escribir . inicializacion.
Cuando vimos la forma de referirse a los parámetros,
salió el delicado tema de que sólo podíamos referirnos a
los parámetros que estén en las primeras nueve posiciones. Esto
es así en el Bourne Shell, y se debe actuar así si se quiere
hacer un guión estándar que se ejecute en cualquier sitio. Pero
en el Korn Shell (y creo que también en bash, aunque no lo he probado)
se pueden escribir los nombres de variables con esta sintaxis:
${variable}. El Bourne Shell acepta esta construcción
cuando son variables normales, pero no cuando lo utilizamos para indicar
parámetros.
Así, el Korn Shell y compatibles, podríamos referirnos
al parámetro 15 con la expresión ${15}. En cualquier
inérprete compatible con el bourne, si quisiéramos escribir
caracteres justo después del contenido de una variable,
deberíamos escribir, por ejemplo:
${foo}bar
Porque si pusiéramos simplemente
$foobar
El intérprete creería que nos referimos a una variable no declarada llamada foobar, con lo que esa expresión sería una ristra vacía.
eval
Hay una orden que algunas veces nos puede sacar de algunos apuros: es
la orden eval. En realidad esta orden no sirve para nada, simplemente,
al ser una orden (como parámetros tenemos que poner otra orden), fuerza
que el intérprete pase dos veces por el mismo sitio, y que
evalúe dos veces la expresión. Así, si
quisiéramos que el usuario introdujera por teclado el nombre de una
variable a modificar, podríamos resolver el problema así:
read nombre
eval $nombre=10
La primera vez que el intérprete lo mirara, la expresión
de eval quedaría como `[contenido de la variable
$variable]=10'. La segunda vez, ejecutaría la orden, como quedara,
con lo que conseguiríamos asignar 10 a una variable cuyo nombre ha sido
elegido por el usuario.