INTÉRPRETE DE COMANDOS :
EL SHELL DE PRESENTACIÓN :
Una gran parte del trabajo de UNIX consiste en emitir ordenes. Al emitir una orden, nos estamos comunicando con el SHELL que proporciona gran parte de las características que hacen de UNIX un sistema operativo flexible. El SHELL de UNIX lo podemos ver desde dos puntos de vista diferentes :
Ofrece estructuras de alto nivel para crear programas que llamaremos guiones del SHELL (SHELL scripts) que indican una serie de pasos para realizar una labor.
Cuando nos presentamos en el sistema UNIX se inicia automáticamente el SHELL incluido en ‘/ etc / passwd’ para el usuario que se conecta ; este SHELL es el SHELL de presentación, se crea como hijo del proceso login y como padre de todos los demás procesos que ejecute el usuario. El SHELL de presentación no termina hasta que el usuario se despide y su terminación provoca el fin de la sesión.
Nosotros estamos conectados mientras exista el SHELL de presentación.
Una vez que el usuario está conectado, la mayor parte de las interacciones con el sistema toman la forma de dialogo con el SHELL. Este diálogo sigue una secuencia simple y repetitiva :
En general la línea de ordenes contiene nombre, argumento y un RTM el SHELL no comienza a procesar la orden hasta que recibe RTM. Si es necesario se pueden realizar varias ordenes con un solo RTM separador por un ‘
; ’.
TIPOS DE SHELL :
El UNIX sistema V versión 4, proporciona tres tipos de SHELL de presentación, que son :
El csh y el ksh se desarrollaron para añadir capacidades adicionales al SHELL estándar, entre ellos la edición de la línea de ordenes, los alias de ordenes y el histórico de comandos.
El SHELL C fue desarrollado por Bill Joy como una ampliación al sistema UNIX de Berkley. Proporciona todas las características del SHELL estándar y un amplio numero de extensiones. Su sistaxis se ajusta al lenguaje de programación C y es bastante diferente de la del SHELL estándar. Resulta muy cómodo para programar en C. Es incompatible con el SHELL estándar.
SHELL DE KORN :
El Korn SHELL fue desarrollado por David Korn en 1982 en los laboratorios Bell , incorpora la mayor parte de las ampliaciones del SHELL C y conserva la sintaxis del SHELL estándar. Amplia el SHELL estándar para mantenerlo la misma sintaxis. Los programas de SHELL estándar funcionasen en Korn. Lo del Korn no funcionan en Korn (debido a ampliaciones).
Ficheros de inicialización :
Cuando se inicia el SHELL de presentación, tanto en SHELL estándar como en SHELL de Korn, se busca un archivo llamado .profile en el directorio de conexión. Este archivo es un fichero de texto que funciona como un guión del SHELL y por tanto contiene instrucciones que se ejecutarán en el momento de la conexión. Los guiones del SHELL son ficheros de texto. El SHELL ejecuta ese guión antes de hacer cualquier cosa. Tiene sentencias de información acerca del sistema y de personalización de variables de entorno.
Nuestra terminal va a ser vt220.
El SHELL indica que está listo para recibir la entrada, visualizando el prompt. Por defecto el prompt principal del SHELL es $ (#
à root ).El SHELL de korn utiliza un archivo adicional al .profile. Este archivo es le que se encuentra en la variable de entorno ENV y se ejecutan después del .profile. Se da el valor a ENV en el .profile. El nombre más habitual es .kshrc ; los fichero que acaban en rc son de configuración. El punto es un archivo de limitación de acceso. El .kshrc es otro fichero de texto.
El fichero de configuración .profile se ejecuta únicamente al iniciar la sesion. El fichero secundario se ejecuta cada vez que se inicializa el SHELL de presentación. Determinados programas tienen la capacidad de generar un "escape" del sistema con lo que anulan el SHELL de presentación y lo reinicializan al terminar. Ej. editor VI
En esta inicialización es cuando se utiliza el .kshrc pero no el .profile.
Variables del SHELL :
El SHELL dispone de un mecanismo para definir variables que pueden contener información para otros procesos o para si mismo. Ej. TER lo utilizarán muchos procesos. Se pueden definirán conjunto de variables estándar y también unas variables personales para almacenar cualquier tipo de información.
La variables del SHELL estándar más comunes son :
Variables más comunes del KSHELL :
Obtención del valor de una variable.
Para obtener el valor de una variable del SHELL debemos indicar el nombre dela variable y anteponer el símbolo $. Cuando el SHELL encuentra una palabra que comienza por $ supone que es una variable, y sustituye su valor por la parición de la variable.
Ej.
echo $LOGNAME
à Sustituye $LOGNAME por F951081 à echo
ls $HOME
à sutituye $HOME por /home/alumnos/... à ls
Esta forma de acceder a la variable es válida tanto para variables del sistema como para variables creadas por el usuario. Es decir, mediante este tipo de acceso podemos acceder a todos las variables predefinidas como creadas por el usuario.
Para visualizar todas las variables declaradas actualmente en el SHELL ejecutamos la orden SET(set).
Definición de variables en el SHELL :
Aunque existen variables cuyo valor se fija automáticamente hay otras a las que necesitamos asignar un valor. Para definir una variable, empleamos la siguiente sintaxis :
nombre=valor
Se puede cambiar el valor de una variable ya definida.
Si la variable no tiene un valor, la variable no existe. Esta es una orden de asignación y definición al mismo tiempo.
El valor puede contener más de una palabra, en esta caso se pondrá entre comillas. Entre el nombre, el valor y el signo =, no pueden existir espacios en blanco.
Exportación de variables :
Las variables propias o internas al SHELL se distinguen de las que se pueden utilizar en otros programas por el entorno al que pertenecen. En una sesión se crean tantos entornos distintos como procesos se estén ejecutando y cada entorno se divide en entorno propio y entorno global.
Las variables que pertenecen al entorno propio de un proceso solo son accesibles desde ese proceso, mientras que las de entorno global son accesibles desde ese proceso y desde todos los procesos hijos de ese.
Una variable propia del SHELL pasa al entorno cuando es exportada.
Para exportar una variable utilizamos :
export nom_var
Ej.
<Estamos en el SHELL de conexión>
P = 3
echo $P {Sale por pantalla un 3}
ksh {Ejecutamos otro entorno K SHELL}
P = 5
echo $P {Sale por pantalla un 5}
export P {Pasa la variable P al entorno del Ksh de ahora}
ksh {Ejecutamos otro entorno K SHELL}
echo $P {Sale por pantalla un 5}
P = 7
exit {Salgo del 2º Ksh}
echo $P {Sale por pantalla un 5}
{Las modificaciones no afectan al padre}
exit {Salgo del 1er Ksh}
echo $P {Sale por pantalla un 3}
ksh {Ejecuto de nuevo un Ksh}
echo $P {ERROR ! variable no declarada}
Existen variables del sistema que por defecto están exportadas (Pertenecen al entorno global).
Ej : HOME, LOGNAME, PS1, PS2...etc.
Variables noclobber e ignoreeof
(en minísculas)
Tanto el Csh como el Ksh utilizan variables especiales llamadas de conmutación para activar o desactivar características. Las variables de conmutación solo pueden tener dos valores : Activado o desactivado. En el SHELL de Korn se gestionan estas variables mediante la orden set con el parámetro -o(activar) y +o(desactivar).
noclobber : Cuando está activada impide sobreescribir en archivos existentes mediante redireccionamiento de salida. Para confirmar la sobreescritura, utilizamos el carácter | .
Ej. ls -l > temp {temp existe} No lo hace ERROR.
ls -l >| temp {temp existe} Se fuerza la sobre escritura.
ignoreeof : La pulsación de CTRL + D equivale a abortar la ejecución. En muchas ocasiones para abortar un proceso hay que pulsar esta combinación varias veces. Esta repetición de teclas puede hacer que además de abortar el proceso, nos salgamos del entorno SHELL de conxión( nos vamos fuera del sitema). La variable ignoreeof cuando está activahace que el SHELL de conexión ignore la pulsación de CTRL + D. Solo protege al SHELL de conexión.
Histórico de órdenes :
El Ksh mantiene un registro de todas las líneas de ordenes introducidas en una sesion (depende del tamaño que se le de a HISTSIZE). Este resgistro permite desarrollar varias caracteristicas de este SHELL.
Visualización y ejecución :
Para ver en cualquier instante las últimas ordenes ejecutadas, empleamos la orden history ; también permite acceder a una orden en particular dándole como parámetro el código de esa línea de órdenes.
Se puede reejcutar una orden mediante el comando r, como parámetros admite tanto la orden a buscar, como el numero de linea en el que se encuentra la orden.(Sin parámetros ejecuta la última orden).
Ej.
r vi
à Retrocede hasta encontrar vi, y lo ejecuta.
El nombre de archivo que suele contener el histórico de comandos, es .sh_history
Edición de línea de ordenes :
El ksh, permite elegir un editor de línea de ordenes para modificar y reejecutar ordenes anteriores.
El editor elegido se encuentra en la variable EDITOR y debe ser asignado por el usuario.
Cuando está activo un editor de línea de ordenes podemos remplazar los comandos de ese editor para movernos por ese fichero histórico. El editor más usual es el VI. Otro importante es EMACS.
Cuando está activado el VI como editor disponemos de una ventana de edición de tamaño una línea sobre el fichero histórico.
ALIAS de órdenes :
Un alias de una orden es una palabra que es sustituida por la orden cuando se usa como comando.
Es similar a una variable, pero usada como comando.
Un ALIAS se ejecuta.
Un ALIAS puede servir para dar otro nombre a ordenes existentes, para simplificar la escritura de ordenes o para sustituir a líneas de ordenes muy largas.
Un ALIAS puede hacer referencia solo a un comando, a un comando como parámetro, e incluso a una sucesión de comandos encadenados unos a otros.
Ej.
alias m = mailx
alias lsc = "ls -lt"
alias cuenta = "who | wc-l"
Para acceder a un ALIAS, basta con escribir su nombre y pulsar <ENTER>.
La vida de los alias alcanza hasta el final de la sesión.
Para que tengamos un alias desde que se inicia la sesión, hay que meterlo en el .profile.
EJECUCION DE ORDENES EN MODO SUBORDINADO :
Normalmente cuando el SHELL ejecuta una orden permanece bloqueado en espera de que finalice.
Durante este tiempo, no atiende peticiones del usuario.
En ocasiones la ejecución de una línea de ordenes se prolonga durante mucho tiempo y no necesita de la interacción con el usuario. En estos casos resulta útil que el SHELL esté dispuesto para recibir nuevas ordenes antes de que termine la orden anterior.
Esto se consigue haciendo que la ejecución de una orden se realice en modo subordinado :
<background>
Para ello al final de la línea de ordenes añado el símbolo ‘&’.
No recibe salida de teclado.
Hace que el SHELL no se pare.
La E/S en modo subordinado :
Cuando se ejecuta una orden en modo subordinado, el SHELL la procesa iniciando los procesos necesarios, emite un mensaje de identificación formado por 2 números y a continuación solicita otra orden. Estos dos números representan identificador de trabajo y el PID del proceso. Desconecta la entrada estándar de la orden en modo subordinado del teclado. Una orden en modo subordinado, no puede aceptar ordenes de teclado), pero no desconecta la salida ni el error de la pantalla (cuando genere una salida va a ir a la pantalla). Esto a veces va a resultar molesto, ya que la salida de la orden subordinada se entremezcla con el echo del teclado sobre la pantalla. Resulta muy útil el archivo /d/null , puesto que todo lo que de error se graba en él.
Mantenimiento de trabajos activos.
Lo normal es que una ejecución en modo subordinado sea de operaciones largas.
Una operación muy larga debe continuar, incluso después de que el usuario haya abandonado el sistema.
En condiciones normales cuando un usuario se despide y mantiene trabajos activos, el núcleo elimina este trabajo, con lo cual los trabajos terminan. (Si yo me desconecto el trabajo se elimina)
Para mantener un trabajo activo una vez que la sesión haya terminado se debe ejecutar el trabajo precedido de la orden NOHUP(nohup) esto le indica al núcleo que el trabajo continua incluido después de acabar la sesión, nohup no me obliga a desconectar.
La orden nohup solo se ejecuta en modo subordinado. Todo lo que se ejecute con nohup lo toma como subordinado, la Entrada, la Salida y el Error, se han de direccionar ; si no se hace la Salida y el Error se almacenan en nohup.out.
Órdenes de control de Trabajos.
Para controlar procesos empleamos el PID de los mismos. Cualquier referencia a un PID identifica a un único proceso en el sistema.
Para visualizar los procesos existentes en el sistema utilizamos la orden PS(ps). PS ofrece información sobre que procesos hay, cual es su PID y cuales son sus otras características.
PID nos puede ofrecer todo : El espacio asignado en memoria, el terminal asociado, los padres e hijos del proceso...etc.
En el SHELL estándar, el único control que se puede establecer sobre un proceso, es su eliminación. La orden KILL(kill) envía un número de señal a un proceso. Cuando un proceso envía una señal para la que no está preparado, el proceso termina.
Cualquier tipo de señal puede eliminar un proceso.
Las señales para utilizar con Kill son :
La diferencia está en la fuerza.
1 à Cuando hay algún error.
2 à Para la finalización.
3 à Finalización "pase lo que pase" à Ningún proceso puede controlarlo. Si yo quiero que un proceso acabe siempre, le doy un nº 9.
Ej.
SHELL
señal 3 : La ignora
señal 10 : La ignora
señal 9 : El SHELL termina.
Cuando una señal acaba con el SHELL termina la sesión.
Los procesos que nosotros hagamos podrán capturar cualquier señal menos la 9.
El SHELL de trabajo.
JSH
Es un SHELL destinado para gestionar trabajos de usuario. Nos permite un control más sencillo y más flexible que el SHELL estandar.
Todas las caracteristicas del Jsh están en el ksh.
Dentro del Jsh podemos referenciar a una orden de dos formas :
El numero de trabajo es un número único para cada trabajo de un usuario.
Los números de trabajo no van a estar salteados como los PID(Son de un solo usuario).
Un trabajo es un conjunto de ordenes ejecutadas explícitamente por el usuario.
El JSH puede :
Apéndice CSHELL al final (Independiente del KSHELL)