Programación Shell-script en Linux

1 Objetivos y alcance

1.1 Introducción

El intérprete de comandos o shell es un programa que permite a los usuarios interactuar con el sistema, procesando las órdenes que se le indican. Los comandos invocables desde el shell pueden clasificarse en internos (corresponden en realidad a órdenes interpretadas por el propio shell) y externos (corresponden a ficheros ejecutables externos al shell). Además de comandos, los shells ofrecen otros elementos para mejorar su funcionalidad, tales como variables, funciones o estructuras de control. El conjunto de comandos internos y elementos disponibles, así como su sintaxis, dependerá del shell concreto empleado.

Además de utilizar el shell desde la línea de comandos (basada en el prompt como la indicación del shell para anunciar que espera una orden del usuario), puede emplearse para la interpretación de shell-scripts. Un shell-script o "guión de órdenes" es un fichero de texto que contiene un conjunto de comandos y órdenes interpretables por el shell.

En los S.O.’s Unix existen múltiples implementaciones de shell (en Windows, el equivalente serían los programas "command.com" o "cmd.exe"). Atendiendo al shell del que proceden y a su similitud sintáctica (incluyendo sus comandos internos), los shells de Unix pueden clasificarse en dos grandes familias (existen algunos shell adicionales, de uso residual y dentro de los shells de una misma familia también existen diferencias, pero gran parte de su sintaxis es común):

1. sh (Bourne Shell): este shell fue usado desde las primeras versiones de Unix (Unix Versión 7). Recibe ese nombre por su desarrollador, Stephen Bourne, de los Laboratorios Bell de AT&T. A raíz de él han surgido múltiples shells, tales como zsh (Z shell), ash (almquist shell), bash (Bourne again shell), dash (Debian almquist shell) o ksh (Korn shell). Por su mayor uso pueden destacarse:
   • bash: fue desarrollado para ser un superconjunto de la funcionalidad del Bourne Shell (en la que incluye funcionalidades de ksh y csh), siendo el intérprete de comandos asignado por defecto a los usuarios en las distribuciones de Linux, por lo que es el shell empleado en la mayoría de las consolas de comandos de Linux. Se caracteriza por una gran funcionalidad adicional a la del Bourne Shell. Como ficheros personales de los usuarios emplea $HOME/.bashrc y .bash_profile.
   • dash (Debian almquist shell), derivado directo de ash, se caracteriza por ser mucho más ligero (depende de menos bibliotecas) y rápido que otros shells, tales como bash, aunque con menos características funcionales. El fichero personal del usuario es $HOME/.profile.
   • ksh (Korn shell): destaca por sus funciones avanzadas para manejar archivos, pudiendo competir con lenguajes de programación especializados tales como awk o perl.

   Bourne Shell ha llegado a convertirse en un estándar de facto de tal modo que todos los sistemas Unix tienen, al menos, una implementación del Bourne Shell (o un shell compatible con él), ubicada en /bin/sh. En el caso concreto de los S.O.’s UNIX Linux, no existe ninguna implementación del Bourne Shell, manteniéndose la entrada  /bin/sh (así como su manual man sh) como un enlace simbólico a una implementación de shell compatible. En concreto:

   • En algunos S.O’s Linux se enlaza a /bin/bash.
   • En Debian, desde Debian Lenny "5.0" (en Ubuntu desde la versión 6.10) se enlaza a /bin/dash: de este modo, estas distribuciones pretenden hacer uso de:
     • dash: para los shell scripts empleados en el arranque del sistema (cuyo shebang tradicionalmente siempre ha sido #!/bin/sh), aprovechando la mayor rapidez de este intérprete.
     • bash: en las consolas de comandos y scripts de servicios de los usuarios, de modo que éstos puedan aprovechar la mayor funcionalidad que éste intérprete ofrece.
2. csh (C shell): caracterizado por presentar una sintaxis muy parecida a la del lenguaje de programación C. Como shell derivados destaca tcsh. Estos shell cuentan con un nivel de uso muy inferior respecto a los de la familia Bourne Shell.

   Para intentar homogeneizar esta diversidad de shells, el IEEE definió un estándar de "intérprete de comandos" bajo la especificación POSIX 1003.2 (también recogida como ISO 9945.2). La creación de dicho estándar se basó en la sintaxis que presentaban múltiples shells de la familia Bourne shell (el propio Bourne Shell de Unix Versión 7, implementaciones en UNIX System V y BSD, así como ksh). Esto ha llevado a que la gran mayoría de los shells derivados del Bourne Shell, tales como bash, dash o ksh, den soporte a este estándar POSIX (mientras que los derivados del csh no). En concreto:

   • bash: respeta completamente el estándar POSIX, sobre el que añade un número considerable de extensiones (estructura select, arrays, mayor número de operadores,...).
   • dash: conforme al estándar POSIX IEEE 1003.2, sólo ampliado con algunas extensiones Berkeley. De forma precisa, tal como indica el manual del intérprete dash de su sistema (man dash), la línea de desarrollo de dash pretende que éste satisfaga el estándar POSIX de shells IEEE 1003.2, propósito casi logrado en la actualidad (sólo presenta algunas características faltantes, como la variable $LINENO).

1.2 Objetivo

El objetivo es introducir el uso del lenguaje de programación de shell-scripts. Consecuentemente, nos centraremos en la sintaxis de shell propuesta por el estándar POSIX IEEE 1003.2 lo que, conforme a lo antes indicado, se traduce en que todo lo visto aquí podrá ser utilizado en dash, bash y cualquier otro shell que satisfaga dicho estándar. Sobre la base de este documento podrá profundizarse analizando las funcionalidades adicionales añadidas por cada shell, siendo de especial interés, dado su uso, las aportadas por bash.

1.3 Documentación de apoyo

• Estándar de "intérprete de comandos" de la especificación POSIX ( IEEE Standard 1003.1 2004/ISO 9945.2)
• The Linux Command Line (Openbook)". E. William, Jr. Shotts. San Francisco, 2011.
• Linux bible". Christopher Negus. Indianapolis, IN. Wiley, 2011. ISBN: 9780470929988.
• Pro Linux System Administration". James Turnbull, Peter Lieverdink, Dennis Matotek. Berkeley, CA. Apress, 2009. ISBN: 978-1-4302-1912-5.
• Linux Network Administrator's Guide (Openbook)". Olaf Kirch, Terry Dawson. O'Reilly, 2000. ISBN: 1-56592-400-2
• Web oficial de Dash
• Manual de referencia de Bash

2 Estructura básica de shell-scripts. Invocación

En su forma más básica, un shell-script puede ser un simple fichero de texto que contenga uno o varios comandos. Para ayudar a la identificación del contenido a partir del nombre del archivo, es habitual que los shell scripts tengan la extensión ".sh", por lo que seguiremos este criterio (pero recuerde que es algo meramente informativo y opcional). Por ejemplo, el siguiente fichero sería un shell-script:

echo "Contenido carpeta personal:"
ls ~/
            

Además de comandos, los shell-scripts pueden contener otros elementos, aportados por el shell para mejorar la funcionalidad de los scripts. De forma resumida, la estructura básica de un shell-script es la siguiente:

#!/bin/dash
# Esto no se interpreta
echo Hola
ps w
echo "Proceso lee el script: $$"
            

<-- Shebang
<-- Comentarios
<-- Contenido


            

Como contenido del script pueden utilizarse múltiples elementos (comandos, variables, funciones, estructuras de control, comentarios,...) que se analizarán en el siguiente apartado.

El "shebang" permite especificar el intérprete de comandos con el que deseamos que sea interpretado el resto del script cuando se usa invocación implícita (ver más adelante). La sintaxis de esta línea es la secuencia #! seguida del ejecutable del shell deseado, sobre lo que deben realizarse la siguientes advertencias:

• Es imprescindible que sea la primera línea del script, ya que, en caso contrario, sería interpretado como un comentario (comienza con el carácter #).
• Puede haber espacios entre #! y el ejecutable del "shell".
• El shebang no es obligatorio (cuando se usa invocación implícita, si no se indica se intentará usar el mismo tipo de shell desde el que se ha invocado el script).

La utilización del shebang está condicionada por la forma en que sea invocado el shell-script, existiendo 3 opciones:

• Explícita: escribiendo explícitamente qué shell se desea invocar y pasando como argumento el nombre del script, cargándose en memoria un nuevo proceso para dicho shell  (subshell o proceso shell hijo del shell padre responsable de la línea de comandos desde la que se ha invocado el script). En este caso se ignora el shebang.
• Implícita: invocando al script como si fuera un ejecutable, lo que requiere asignar permisos de ejecución al script. Se lee el shebang para determinar qué shell deberá usarse para leer el script, cargándose en memoria un proceso hijo (subshell) para dicho shell (si el script no presenta shebang, para el subshell se utilizará el mismo tipo de shell que el encargado de la línea de comandos desde la que se ha hecho la invocación). Tenga en cuenta que los shell-scripts son ficheros de texto leídos por el intérprete de comandos, esto es, se interpretan, NO se ejecutan. La asignación del permiso de ejecución a un shell-script es una utilidad del sistema de ficheros para acelerar la invocación de scripts, pero cuyo funcionamiento interno es cargar un nuevo proceso de shell (subshell) para que éste interprete el script.
• Implícita con . (equivale a importar): el script será interpretado por el mismo proceso del shell responsable de la línea de comandos desde la que se está invocando el script (luego aquí no se abre ningún subshell). Consecuentemente, en este caso también se ignora el shebang.

En los casos en los que se crean subshells, salvo que se fuerce lo contrario (con su -c por ejemplo), el subshell pertenecerá al mismo usuario al que pertenecía el shell padre que lo ha creado. El usuario al que pertenece el proceso shell que interpreta un script condiciona las operaciones que se podrán hacer desde dentro del script (por ejemplo, si el shell pertenece al usuario dit , el script no podrá modificar el fichero /etc/passwd , mientras que si el shell pertenece al superusuario root , sí podrá hacerlo). Tenga en cuenta este aspecto para determinar qué operaciones puede realizar dentro de un script, y con qué usuario debe invocarlo.

Conforme se ha indicado en la introducción, si bien tanto bash como dash siguen el estándar POSIX, especialmente bash añade múltiples extensiones particulares, no soportadas por otros shells como dash. Consecuentemente, cada vez que diseñemos un script deberemos tener en cuenta el shell o shells que lo soportan, asegurando que sea invocado por uno de ellos. Para que se haga una idea de la importancia de este aspecto, considere los dos scripts siguientes, basados en el uso de la estructura for (que se usará más adelante):

#!/bin/sh for VAR in 0 1 2 3
do
   echo $VAR
done
            

#!/bin/bash
for ((VAR=0 ; VAR<4 ; VAR++ ))
do
   echo $VAR
done
            

Ambos scripts realizan la misma funcionalidad, pero script_estandar.sh está escrito bajo la sintaxis POSIX, mientras que script_bash.sh utiliza una sintaxis no estándar soportada por bash.

3 Sintaxis de Shell-scripts

En este apartado se describe el lenguaje de comandos shell definido en el estándar POSIX. Veremos el funcionamiento general del shell, así como su sintaxis. Puede encontrar la descripción detallada del estándar POSIX en el siguiente enlace: POSIX Shell Command Language

Aquí se resumen las características más utilizadas. Se recomienda acudir al estándar para obtener una descripción más detallada y exhaustiva.

echo "Mal definida":
echo "(orden no encontrada)":
VAR = 1
echo "Variables bien definidas:"
VAR=1
VAR1=2
var=3
echo "Variables: $VAR $VAR1 $var"
echo "Variable VAR: $VAR"
echo "Variable VAR1: $VAR1"
echo "VAR seguida de 1: ${VAR}1"
echo "Comillas dobles: $VAR"
echo 'Comillas simples: $VAR'
echo "Valor: $VAR-1"
                  

#!/bin/sh
echo \$@=$@
echo \$*=$*
echo \$0=$0
echo \$1=$1
echo \$2=$2
echo Cambio parametros posicionales
set uno dos tres
echo \$1=$1
echo \$2=$2
echo Desplazo
shift
echo \$1=$1
echo \$2=$2
echo \$-=$-
echo \$#=$#
echo \$?=$?
firefox &
ps w
echo \$$=$$
echo \$!=$!
                  

#!/bin/bash
export VAR=a
echo $VAR
ps w
./script_hijo.sh
echo $VAR

#!/bin/sh
echo $VAR
VAR=b
echo $VAR
ps w

#!/bin/bash
VAR=a
echo $VAR
ps w
. script2.sh
echo $VAR

#!/bin/sh
echo $VAR
VAR=b
echo $VAR
ps w

#!/bin/sh
fun1(){...}
fun2(){...}
#...

#!/bin/sh
VARa=1
VARb=2
#...

#!/bin/sh
. /dir/cont_var.sh
. /dir2/cont_fun.sh
fun1 $VARb
#...

#!/bin/sh
VAR=1
echo $VAR
unset VAR
echo ${VAR:-2}
echo $VAR
FICH=fichero.c
echo ${FICH%.c}.o

#!/bin/sh
VAR=1
echo $VAR
unset VAR
echo ${VAR:=2}
echo $VAR
FICH=/usr/bin/prueba
echo ${FICH##*/}

#!/bin/sh
VAR=1
VAR=$VAR+1
echo $VAR
RES1=$(($VAR))+1
echo $RES1
VAR=1
RES2=$((VAR+1)) #VAR no necesita $
echo $RES2
VARb=b
echo $(($VARb+1)) #VARb necesita $

#!/bin/sh
head -1 /etc/passwd && echo "Sin error1A" || echo "Con error1B"
head -1 /nofile && echo "Sin error2A" || echo "Con error2B"
echo "Comando dividido \
en dos líneas"
echo "Sin escapado: $$"
echo "Con escapado: \$\$"
echo "N º de proceso del shell bash:" `pidof bash`

#!/bin/sh

suma () {
    C=$(($1+$2))
    echo "Suma: $C"
    return $C
    echo "No llega"
}

suma 1 2
suma $1 $2 #suma los 2 primeros argumentos
echo "Valor devuelto: " $? 

echo " Introduzca una cadena "
read CAD
echo " Cadena introducida: $CAD "

echo "Pulse intro para continuar..."
read CAD
echo " Continuamos... "

#ejemplo de referencia indirecta con eval
VAR="Texto"
REF=VAR             #REF es una variable que vale VAR
eval OTRA='$'$REF   #equivale a ejecutar OTRA=$VAR
echo $OTRA          #se ha accedido al contenido de VAR a través de REF

4 Depuración de shell-scripts

Si bien la programación de shell-scripts no se puede depurar fácilmente, los shells suelen ofrecer algunos mecanismos en este aspecto. En concreto, tanto "bash" como "dash" ofrecen los siguientes argumentos, que pueden usarse simultáneamente:

También es posible depurar sólo parte del script insertando en él los siguientes comandos (pueden usarse igualmente en la propia línea de comandos):

5 Propuesta de ejercicios

A continuación se le propone la creación de una serie de scripts. Para ello, será necesario tanto usar los conocimientos expuestos en este documento, como otros relativos a la administración de Linux:

1. Los ficheros /etc/profile (leído en el arranque del sistema y común para todos los usuarios), ~/.bashrc, ~/.bash_profile (leídos al abrir una sesión con el usuario correspondiente, no es necesario que existan ambos), usados para cargar las variables de entorno, son en realidad shell-scripts. Analice el contenido de dichos scripts y modifíquelos convenientemente para definir los alias:
   • alias red='ifconfig -a': para todos los usuarios del sistema.
   • alias casa='echo $PWD': sólo para el usuario normal.
   • alias sockets='netstat -l': sólo para el usuario root.

   Repita lo anterior pero utilizando funciones en vez de alias.

2. Cree los siguientes scripts:
   • variables.sh: debe inicializar las variables CONFIG='-a', ARP='-n' y ROUTE.
   • funciones.sh: debe definir las funciones arranque_red() (encargada de activar la tarjeta "eth0"), parada_red() (encargada de desactivar la tarjeta eth0) y estado_red() (encargada de ejecutar los comandos ifconfig, arp y route aplicándoles los parámetros pasados a la función en los argumentos 1, 2 y 3, respectivamente).
   • script1.sh: debe importar las variables y funciones definidas por los dos scripts anteriores. Mostrará al usuario un menú en el que le pregunte si desea arrancar la red (invocando la función arranque_red()), pararla (función parada_red()) o mostrar su estado (función estado_red()). Debe comprobar si alguna de las variables  CONFIG, ARP y ROUTE es nula y, en caso de serlo, permitirle al usuario escribir interactivamente (mediante la función read) los parámetros con los que invocar el comando correspondiente.
3. script_copy.sh: script que copie un fichero regular en otro, ambos pasados como argumentos. Si no se le pasan los argumentos, lo comprobará, y solicitará al usuario que los introduzca interactivamente.
4. script_print.sh: script que imprima en pantalla el contenido de un fichero de datos, o el contenido de todos los ficheros de un directorio, según se le pase como argumento un fichero regular o un directorio.
5. script_borrar.sh: script que borre con confirmación todos los ficheros pasados como argumentos.
6. script_sesiones.sh: script al que, pasándole el login de un usuario, devuelva cuántas sesiones tiene abiertas en el sistema.
7. script_mostrar.sh: script que para cada argumento que reciba (puede recibir una lista de argumentos) realice una de las siguientes operaciones:
   • Si es un directorio, ha de listar los ficheros que contiene.
   • Si es un fichero regular, tiene que imprimir su contenido por pantalla.
   • En otro caso, debe indicar que no es ni un fichero regular ni un directorio (por ejemplo, un fichero de bloques o de caracteres del directorio /dev).
8. script_ejecucion.sh: script que asigne el permiso de ejecución a los ficheros regulares o directorios pasados como argumento (puede admitir una lista de ficheros).
9. script_doble.sh: script que pida un número por teclado y calcule su doble. Comprobará que el número introducido es válido y, antes de terminar, preguntará si deseamos calcular otro doble, en cuyo caso no terminará.
10. script_tipos.sh: script que devuelva el número de ficheros de cada tipo (ficheros regulares o directorios) que hay en una determinada carpeta, así como sus nombres. Tendrá un único argumento (opcional) que será la carpeta a explorar. Si se omite dicho argumento, se asumirá el directorio actual. Devolverá 0 (éxito) si se ha invocado de forma correcta o 1 (error) en caso contrario.
11. script_user.sh: script que reciba como argumento el login de un usuario e imprima por pantalla la siguiente información: login, nombre completo del usuario, directorio home, shell que utiliza, número de sesiones actualmente abiertas y procesos pertenecientes a dicho usuario. El script debe permitir las siguientes opciones:
    • -p: sólo muestra la información de los procesos.
    • -u: muestra toda la información excepto la referente a los procesos.
    • --help: muestra información de ayuda (uso del script).

    El script debe comprobar si los argumentos pasados son correctos, así como la existencia del usuario indicado. Como código de error podrá devolver 0 (éxito), 1 (sintaxis de invocación errónea), 2 (usuario no existe).

12. script_menu.sh: script que ofrezca al usuario un menú (con una opción para salir) desde el que el usuario pueda seleccionar cual de los scripts anteriores (apartados "b)" a "k)") quiere utilizar.
13. script_puerto.sh: script que reciba como argumento un número de puerto TCP (PUERTO) y comprobará si el valor es un número entero positivo en el rango "[1, 1023]", de modo que:
    • Si es así: el script analizará si los puertos TCP "PUERTO" y "PUERTO+1" del equipo local se encuentran a la escucha. Tras ello, imprimirá un mensaje indicando el estado obtenido. Para ello, puede analizar la salida del comando netstat.
    • En otro caso: imprimirá por pantalla un mensaje indicando que el valor indicado no es un puerto de sistema.
14. script_arp.sh: script que reciba como argumento un número entero, guardándolo en la variable POS_ARP. El script comprobará si el valor de la variable POS_ARP es un número entero positivo, de modo que:
    • Si es así: el script calculará el número de entradas que actualmente tiene la caché ARP del equipo, guardándolo en la variable NENTRADAS. Si el valor de POS_ARP es mayor que NENTRADAS, imprimirá por pantalla un mensaje tal como: Ninguna entrada en la posición POS_ARP. En caso de que POS_ARP sea menor o igual que NENTRADAS, imprimirá por pantalla un mensaje con la posición de la entrada ARP POS_ARP, seguido del contenido de dicha entrada ARP.
    • En otro caso: Imprimirá por pantalla un mensaje indicando que el valor indicado no es un número entero: Posición de entrada ARP no válida

    Se solicitan dos posibles soluciones:

    • script_arp1.sh: Basada en el comando read y estructuras de control.
    • script_arp2.sh: Analizando la salida del comando arp mediante comandos de análisis de texto.
15. script_param.sh: Considere que en el shell actual se dispone de la variable:

    VAR="nombre=v1&edad=v2&tlf=v3"

    Escriba un shell-script que analice el valor de dicha variable y para cada uno de los parámetros extraiga su valor y lo imprima por pantalla. Por ejemplo, que la salida sea:

    Cadena analizada: nombre=v1&edad=v2&tlf=v3 nombre: v1, edad: v2, tlf: v3.

    Se solicitan dos posibles soluciones:
    • script_param1.sh: Usando la variable de entorno IFS.
    • script_param2.sh: Sin usar IFS.

6 Anexo: Descriptores de ficheros y redirecciones

Para facilitar el acceso a los distintos recursos del sistema (zona de almacenamiento en disco, teclado, pantalla, socket,...), el kernel de Linux vincula cada recurso con un fichero, real (espacio en disco) o virtual (en memoria, como /dev y /proc). Ejemplos habituales son:

Cuando un proceso necesita acceder a un recurso, debe realizar las siguientes operaciones:

1. Abrir el fichero correspondiente a dicho recurso: el proceso indica al sistema la ruta del fichero, especificando su intención de abrirlo para lectura (obtener información del recurso), escritura (enviar información al recurso) o lectura/escritura; el sistema concederá el tipo de acceso solicitado según las características del recurso (teclado, pantalla, ...) y los permisos que el usuario efectivo del proceso posea sobre el fichero. Como respuesta, el sistema devolverá al proceso el descriptor (o descriptor de fichero) con el que el proceso podrá acceder al fichero.
2. Acceder al fichero/recurso usando el descriptor suministrado por el sistema: el proceso indicará el descriptor al kernel, éste localiza el fichero y accede al recurso asociado.

Un descriptor no es más que un número entero "n", con las siguientes características:

• Cada proceso tiene su propia tabla de descriptores para acceder a los recursos/ficheros; el fichero que un proceso tenga asociado al descriptor "n" es independiente del que puedan tener asociado para ese mismo descriptor los demás procesos del sistema. El conjunto de descriptores que tiene asociados un determinado proceso puede obtenerse con ls /proc/PID/fd/, cambiando PID por el identificador de dicho proceso.
  
  

  Proceso con PID xxxx
  Fichero	Descriptor
  Fichero_A	0
  Fichero_B	1
  Fichero_C	2
  ...	...

   

• Se dice que un descriptor es de entrada, salida o entrada/salida según el fichero al que esté asociado en ese instante (es posible cambiar el fichero al que está asociado un descriptor) haya sido abierto por el proceso que posee dicho descriptor para lectura, escritura o lectura/escritura, respectivamente.

Al trabajar con un intérprete de comandos encontramos que, de manera habitual, los comandos suelen imprimir su información en pantalla y obtenerla del teclado. Este funcionamiento se debe a los dos motivos siguientes:

1. Muchas aplicaciones, especialmente pensadas para ser usadas en modo consola, son programadas para que, por defecto (sus procesos):
   • Obtengan datos del (recurso asociado al) descriptor "0": dado que éste es el descriptor del que convencionalmente las aplicaciones obtienen información, este descriptor suele denominarse "entrada estándar (a pesar de este nombre, dado su uso especial, internamente los descriptores “0, 1, 2” son de entrada/salida).
   • Envíen su información al (recurso asociado al) descriptor "1": dado que éste es el descriptor al que convencionalmente las aplicaciones envían su información, este descriptor suele denominarse "salida estándar".
   • Envíen su información de errores al (recurso asociado al) descriptor "2": dado que éste es el descriptor al que convencionalmente las aplicaciones envían su información de errores, este descriptor suele denominarse "salida de error estándar".

   Esta configuración "estándar" es la empleada por los comandos POSIX. Así, por ejemplo, los comandos "echo cadena" o "cat fichero" están preparados para imprimir (enviar la información) en el recurso asociado al descriptor 1 (salida estándar), o el comando cat (sin argumentos) está diseñado para obtener la información del recurso asociado al descriptor 0 (entrada estándar).

2. De forma habitual, el proceso (shell) de cualquier consola en modo comandos asocia el descriptor:
   • 0: al recurso "teclado (siempre, a través del fichero asociado a esos dispositivos (/dev/uinput,...), que puede variar según su tipo).
   • 1: al recurso "pantalla".
   • 2: al recurso "pantalla".

   Por omisión, cuando un proceso padre crea un proceso hijo, el proceso hijo sólo dispone de los descriptores "0, 1, 2", cada uno asociado al mismo recurso que en el proceso padre (el proceso hijo hereda la asociación descriptor-fichero para esos tres descriptores, el resto de descriptores no se "heredan"). Todo ello lleva a que en una consola de comandos, las órdenes "echo cadena" o "cat fichero" suelan imprimir por pantalla (recurso del descriptor 1), o el comando cat (sin argumentos) obtenga la información del teclado (recurso del descriptor 0), al heredar esa asociación descriptor-fichero del shell (proceso padre).

Sobre este comportamiento habitual, los intérpretes de comandos de Linux permiten:

• Modificar el fichero (recurso) asociado a cada descriptor estándar "0, 1, 2".
• Asociar ficheros a los descriptores no estándar (3 y posteriores).

Para ello, la sintaxis a aplicar varía según el proceso sobre el que queramos establecer la nueva asociación fichero-descriptor sea el propio proceso shell que estamos utilizando, o sobre un comando (proceso hijo) invocado desde este shell (en programación C, por ejemplo, se realizaría con la función "open", entre otras).

6.1 Asociación para el Proceso Shell actual

Para ello se emplea el comando "exec", mediante las siguientes sintaxis:

Por ejemplo, el siguiente comando permite asociar el archivo /tmp/fichero con el descriptor "4":

exec 4< /tmp/fichero

A partir de ello,  cada vez que queramos que un comando realice operaciones de lectura/escritura sobre ese archivo, podremos aplicar los operadores de redirección (detallados más abajo) con dicho descriptor (en lugar de usar el nombre del archivo).  Por ejemplo, para que el comando ls; envíe su información a ese archivo:

ls >&4

6.2 Asociación para un comando (proceso hijo) invocado desde el shell

Ello se consigue mediante la técnica de "redirección", basada en la siguiente sintaxis (es importante que no haya espacios entre n y op) :

comando    [n]op    fichero/descriptor

donde:

• comando: comando sobre el que aplicar la redirección. Recuerde que, conforme a la sintaxis de los comandos simples, la redirección puede escribirse tanto después como antes del comando.
• n (número entero, opcional): descriptor (asociado actualmente o no a algún fichero en el shell actual). POSIX exige que se soporten, al menos, los valores 0, 1,..., 9. El valor por omisión depende del operador empleado.
• op: operador de redirección. Si se "escapa" el descriptor n se usará el descriptor por omisión (e.g. echo \2>fichero asumirá el descriptor 1). Si se escapa el operador de redirección, no se aplicará redirección alguna (e.g., echo 2\>fichero imprime 2\>fichero al recurso del descriptor 1)
• fichero/descriptor; a asociar (según indique el operador) con el descriptor n descriptor.

Al aplicar esa redirección sobre el comando, para el descriptor n, el comando (el proceso hijo que se crea) no heredará (aún en el caso de ser n=0, 1 o 2) la asociación descriptor-fichero del proceso shell padre, sino que asociará a dicho descriptor n el "fichero" explícitamente indicado.

A continuación se resumen los operadores de redirección definidos por el estándar POSIX, agrupadas según operen sobre descriptores para entrada (lectura de fichero) o salida (escritura en fichero):

1. Redirecciones de entrada: por omisión, toman n=0 (entrada estándar).
   
   

   Redirección	Funcionalidad: El shell invoca comando como proceso hijo, configurándolo para que:
   cmd [n]< fich	Asocie el descriptor de entrada (recuérde que, para abreviar, se está usando el calificativo "descriptor de entrada" para indicar que en ese instante el descriptor está asociado con un fichero abierto para lectura, pero puede cambiar) n; con fich (archivo regular). Por omisión n=0, esto es, cmd < fich hace que para el proceso cmd, el descriptor 0 quede asociado a fich para lectura.
   cmd [n]<&m	Asocie el descriptor de entrada n con el mismo fichero al que actualmente está asociado el descriptor m. Dicho fichero estará así referenciado desde dos descriptores (duplicado de descriptores). m es obligatorio.
   cmd [n]<&-	Cierre el descriptor de entrada n (elimina su asociación con el fichero al que actualmente esté vinculado). Si el descriptor no está asociado con ningún fichero, dará error.
   cmd [n]<< delim	Asocie el descriptor de entrada n con el recurso especial Here-Document (texto empotrado). Tras ejecutar la orden, aparecerá en consola el carácter >; el texto introducido a partir de entonces será guardado en el recurso Here-Document, terminando cuando se introduzca una línea que sólo contenga (incluidos espacios en blanco) la cadena delim (delimitador) y se pulse nueva línea; en dicho momento, comando será ejecutado (pudiendo acceder al contenido del recurso Here-Document a través del descriptor n). Si al escribir la orden, la cadena delim se introduce entre comillas, el shell las eliminará, de modo que para terminar de escribir en el recurso Here-Document, habrá que escribir la cadena delim sin comillas.
   cmd <<- delim	Ídem <<, pero las tabulaciones añadidas al principio de línea será omitidas, no insertándose en el recurso Here-Document.

2. Redirecciones de salida: por omisión, toman n=1 (salida estándar).
   
   

   Redirección	Funcionalidad: El shell invoca comando como proceso hijo, configurándolo para que:
   cmd [n]> fich	Asocie el descriptor de salida n con fich (archivo regular). Por omisión n=1, esto es, cmd > fich hace que para el proceso cmd, el descriptor 1 quede asociado a fich. Si fich no existe, será creado; si existe, será limpiado previamente. Salvo que se haya activado en el shell la opción “no sobrescribir” con el comando set -C (recuerde que el comando set permite modificar el comportamiento del shell, incluyendo opciones y el valor de sus variables) en cuyo caso dará error.
   cmd [n]>| fich	Ídem >, sin depender de la opción "no sobrescribir" (set -C).
   cmd [n]>> fich	Ídem >, sin limpiar previamente el fichero si existe (insertando al final del contenido existente).
   cmd [n]>& m	Asocie el descriptor de salida n con el mismo fichero al que está asociado el descriptor m. Dicho fichero estará así referenciado desde dos descriptores (duplicado de descriptores). m es obligatorio.
   cmd [n]>& -	Cierre el descriptor de salida n (elimina su asociación con el fichero al que actualmente esté vinculado). Si el descriptor no está asociado con ningún fichero, dará error.

3. Redirecciones de entrada/salida: por omisión, toman n=1 (salida estándar).
   
   

   Redirección	Funcionalidad: El shell invoca comando como proceso hijo, configurándolo para que:
   cmd [n]<>fichero	Asocie el descriptor n de entrada y salida con fichero (archivo regular, será creado si no existe).

    

Además de las anteriores, existe un tipo especial de redirección denominado tubería o  "pipeline", en la cual el "recurso" sería esa "tubería" que conecta dos descriptores. Esta redirección se basa en la siguiente sintaxis:

comando1  |  comando2

bajo la cual, el descriptor 0 de comando2 se asociaría con el descriptor 1 de comando1 (esto es, lo que comando1 envíe a su salida estándar será redirigido a la entrada estándar de comando2). Pueden usarse dos o más comandos separados por |.

A continuación se proponen varios ejemplos de redirección y su explicación:

Adicionalmente a lo anterior, deben realizarse las siguientes aclaraciones sobre las redirecciones:

1. Las redirecciones son aplicables a cualquier comando, incluso a subshells (shell abierto desde otro shell), de modo que todos los comandos abiertos desde dicho subshell heredarán por defecto su asociación de los descriptores 0, 1, 2. Por ejemplo, si en un shell ejecutamos:

   echo "Hola" > /tmp/fichero

   /bin/bash < /tmp/fichero

   con el segundo comando se estará abriendo un nuevo proceso shell (subshell), el cual tendrá asociado el descriptor 0 con el archivo /tmp/fichero. Si en dicho subshell abierto ejecutamos ahora:

   cat

   este comando hereda la configuración del subshell, teniendo igualmente asociado el descriptor 0 con el archivo /tmp/fichero. El comando cat, al ser invocado sin argumentos, sigue el estándar POSIX, imprimiendo en el recurso asociado al descriptor 2 (la pantalla en este caso) la información obtenida del recurso asociado al descriptor 0, que en este caso será el archivo fichero; (y no el teclado). Consecuentemente, el resultado es que dicho comando cat imprime directamente por pantalla el contenido de fichero. El orden de lectura de los comandos es importante. Por ejemplo, (cat << fin) < fichero no hará que fichero se pase a cat, dado que < fichero no se aplicará hasta que no haya terminado el comando cat. Por ejemplo:

   cat                ["Ctrl-D" para terminar, que equivale a enviar EOF]

   cat << fin     [Teclear "fin" y Enter para terminar]

2. El orden en el que se escriban las redirecciones es importante, pudiendo cambiar el resultado. Por ejemplo, en el comando:
   • ls /tmp 2> file 1>&2: sucedería lo siguiente (en este orden):
     • El descriptor 2 se asocia con file.
     • El descriptor 1 se asocia con el mismo fichero al que está asociado el descriptor 2, luego con file también.
     • Se ejecuta el comando ls, que enviará sus salidas estándar (1) y de errores (2) a file. En un comando simple, el comando siempre se ejecuta tras aplicar las posibles expansiones/sustituciones e interpretar las redirecciones (leyéndose en orden de izquierda a derecha).
   • 1>&2 ls /tmp 2> file : sucederá lo siguiente (en este orden):
     • El descriptor 1 se asocia con el mismo fichero (o recurso, e.g. pantalla) al que actualmente esté asociado el descriptor 2.
     • El descriptor 2 se asocia con file.
     • Se ejecuta el comando ls, que enviará su salida de errores a file, y su salida estándar (1) con ese recurso (posiblemente pantalla) al que inicialmente estuviese asociado el descriptor 2.
3. Para redireccionar una información a "ninguna parte" se usa el fichero nulo /dev/null (fichero que podría considerarse asociado al recurso virtual "destructor de información") . Por ejemplo, el siguiente comando haría toda la información que ls envíe a la salida estándar (descriptor 1) y a la salida de errores (descriptor 2) sea enviada a /dev/null (se elimina):

   ls -l /usr > /dev/null 2>&1

Por último, advertir que la explicación anterior corresponde al estándar POSIX. Algunos intérpretes de comandos como Bash soportan otros operadores (además de los POSIX). A continuación se resumen algunos de los ofrecidos por Bash: