Comme vous avez pu le réaliser à la suite d'une utilisation rudimentaire du Shell, l'entrée et la sortie d'une commande peuvent être redirigées avant son exécution, grâce à la notation appropriée - les opérateurs de redirection - interprétée par le Shell. La redirection peut aussi être employée pour ouvrir et fermer des fichiers dans l'environnement d'exécution du Shell.

La redirection peut aussi se produire dans le script, de sorte qu'il puisse recevoir son entrée depuis un fichier, par exemple, ou qu'il puisse envoyer les résultats vers un fichier. Ultérieurement, l'utilisateur peut visualiser le fichier de résultat, ou il peut être exploité en entrée par un autre script.

Les fichiers d'entrée et de sortie sont désignés par des entiers indicateurs qui repèrent tout les fichiers ouverts d'un processus donné. Ces valeurs numériques sont connues sous le nom de descripteurs de fichiers. Les descripteurs les plus courant sont stdin, stdout et stderr, avec les numéros 0, 1 et 2, respectivement. Ces numéros et leur entité respective sont réservés. Bash peut aussi considérer des ports TCP ou UDP sur les hôtes du réseau en tant que descripteur.

L'affichage ci-dessous montre comment les descripteurs réservés pointent sur des entités concrètes:

michel ~> ls -l /dev/std*
lrwxrwxrwx  1 root    root     17 Oct  2 07:46 /dev/stderr -> ../proc/self/fd/2
lrwxrwxrwx  1 root    root     17 Oct  2 07:46 /dev/stdin -> ../proc/self/fd/0
lrwxrwxrwx  1 root    root     17 Oct  2 07:46 /dev/stdout -> ../proc/self/fd/1

michel ~> ls -l /proc/self/fd/[0-2]
lrwx------  1 michel  michel   64 Jan 23 12:11 /proc/self/fd/0 -> /dev/pts/6
lrwx------  1 michel  michel   64 Jan 23 12:11 /proc/self/fd/1 -> /dev/pts/6
lrwx------  1 michel  michel   64 Jan 23 12:11 /proc/self/fd/2 -> /dev/pts/6

Vous pouvez consulter info MAKEDEV et info proc pour plus de détails sur le sous-répertoire /proc et la façon dont votre système gère les descripteurs standards de chaque processus lancé.

Quand vous lancez un script depuis la ligne de commande, rien ne change tellement parce que le processus Shell enfant utilisera les mêmes descripteurs que son parent. Quand le parent n'existe pas, par exemple quand vous lancez un script par l'outil cron les descripteurs standards sont des tubes et autres fichiers (temporaires), à moins qu'un autre moyen de redirection soit employé. Ceci est démontré dans l'exemple ci-dessous, lequel produit le résultat avec un simple script at:

michel ~> date
Fri Jan 24 11:05:50 CET 2003

michel ~> at 1107
avertissement: les commandes seront exécutées avec (par ordre) 
a) $SHELL b) login shell c)/bin/sh
at> ls -l /proc/self/fd/ > /var/tmp/fdtest.at
at> <EOT>
job 10 at 2003-01-24 11:07

michel ~> cat /var/tmp/fdtest.at
total 0
lr-x------    1 michel michel  64 Jan 24 11:07 0 -> /var/spool/at/!0000c010959eb (deleted)
l-wx------    1 michel michel  64 Jan 24 11:07 1 -> /var/tmp/fdtest.at
l-wx------    1 michel michel  64 Jan 24 11:07 2 -> /var/spool/at/spool/a0000c010959eb
lr-x------    1 michel michel  64 Jan 24 11:07 3 -> /proc/21949/fd

Et un avec cron:

michel ~> crontab -l
# NE PAS EDITER CE FICHIER - éditer le modèle et le réinstaller.
# (/tmp/crontab.21968 installed on Fri Jan 24 11:30:41 2003)
# (Cron version -- $Id: chap8.xml,v 1.8 2005/09/05 12:39:22 tille Exp $)
32 11 * * * ls -l /proc/self/fd/ > /var/tmp/fdtest.cron

michel ~> cat /var/tmp/fdtest.cron
total 0
lr-x------    1 michel michel  64 Jan 24 11:32 0 -> pipe:[124440]
l-wx------    1 michel michel  64 Jan 24 11:32 1 -> /var/tmp/fdtest.cron
l-wx------    1 michel michel  64 Jan 24 11:32 2 -> pipe:[124441]
lr-x------    1 michel michel  64 Jan 24 11:32 3 -> /proc/21974/fd

Dans l'exemple précédent il apparaît clairement que vous pouvez fournir les fichiers d'entrée et de sortie à un script (voir Section 2.4, « Fichier d'entrée et fichier de sortie » pour plus de détails), mais certains oublient de rediriger les erreurs - un affichage dont peut dépendre la suite. Aussi, si vous êtes chanceux, les erreurs vous seront adressées par mail et d'éventuels dysfonctionnements pourront vous apparaître. Si vous n'êtes pas chanceux, les erreurs feront planter votre script et ne seront ni capturées ni adressées nulle part, par conséquent vous ne pourrez débugger.

Quand vous redirigez les erreurs, faites attention à l'ordre de préséance. Par exemple, cette commande lancée dans /var/spool

ls -l * 2 > /var/tmp/unaccessible-in-spool

redirigera l'affichage de la commande ls dans le fichier unaccessible-in-spool in /var/tmp. La commande

ls -l * > /var/tmp/spoollist 2 >& 1

redirigera et le standard d'entrée et le standard d'erreur vers le fichier spoollist. La commande

ls -l * 2 >& 1 > /var/tmp/spoollist

dirige seulement le standard de sortie vers le fichier de destination, parce que le standard d'erreurs est copié vers le standard de sortie avant que le standard de sortie soit redirigé.

Par commodité, les erreur sont souvent redirigées vers /dev/null, si il est sûr qu'elles n'ont pas d'intérêt. Des centaines d'exemples peuvent être trouvés dans les scripts de lancement de votre système.

Bash autorise à la fois le standard de sortie et le standard d'erreurs à être redirigés vers le fichier dont le nom est le résultat de l'expansion de FILE avec cette forme:

C'est l'équivalent de > FILE 2>&1, la forme employée dans les exemples précédents. C'est aussi combiné souvent avec la redirection vers /dev/null, par exemple quand vous voulez juste qu'une commande s'exécute, quelque soit le résultat ou le statut qu'elle donne.

Le répertoire /dev/fd contient des entrées nommées 0, 1, 2, etc. Ouvrir le fichier /dev/fd/N est équivalent à dupliquer le descripteur N. Si votre système possède /dev/stdin, /dev/stdout et /dev/stderr, vous verrez qu'ils sont équivalents à /dev/fd/0, /dev/fd/1 et /dev/fd/2, respectivement.

La principale utilisation des fichiers /dev/fd est faites par le Shell. Ce mécanisme permet aux programmes qui utilisent des chemins en paramètre de voir le standard d'entrée et le standard de sortie de la même façon que d'autres chemins. Si /dev/fd n'est pas disponible sur votre système, vous devrez trouver un moyen pour résoudre ce problème. Ce qui peut être fait, par exemple, avec un tiret (-) qui indique que le programme doit lire depuis un tube. Un exemple:

michel ~> filter body.txt.gz | cat header.txt - footer.txt
Ce texte est affiché au début de chaque travail d'affichage et merci à l'administrateur d'avoir mis en place une si bonne infrastructure d'affichage.

Texte à filtrer.

Ce texte est à afficher à la fin de chaque travail d'affichage.

La commande cat d'abord lit le fichier header.txt, puis son standard d'entrée lequel est le standard de sortie de la commande filter, et finalement le fichier footer.txt. Le sens spécial du tiret en tant que paramètre de ligne de commande pour se référer au standard d'entrée ou de sortie est une confusion qui a perduré dans beaucoup de programme. Il peut aussi y avoir des problèmes quand vous spécifiez le tiret en tant que premier paramètre, puisqu'il peut être interprété comme une option de la commande précédente. L'usage de /dev/fd permet l'uniformité et évite la confusion:

michel ~> filter body.txt | cat header.txt /dev/fd/0 footer.txt | lp

Dans cet exemple propre, toutes les sorties sont cumulées dans l'entonnoir lp pour les envoyer vers l'imprimante par défaut.

Parce que les processus enfants héritent des descripteurs ouverts, c'est une bonne pratique que de fermer les descripteurs quand on en a plus besoin. Ceci est fait avec la syntaxe suivante

syntax. Dans l'exemple ci-dessus, le descripteur 7, qui a été assigné au standard d'entrée, est fermé chaque fois que l'utilisateur a besoin d'utiliser le périphérique d'entrée standard, habituellement le clavier.

Suit un exemple simple de redirection du standard d'erreurs sur un tube:

michel ~> cat listdirs.sh
#!/bin/bash

# Ce script garde le standard de sortie, tandis qu'il redirige le standard d'erreurs 
# afin d'être traité par awk.

INPUTDIR="$1"

exec 6>&1

ls "$INPUTDIR"/* 2>&1 >&6 6>&- \
				# Closes fd 6 for awk, but not for ls.

| awk 'BEGIN { FS=":" } { print "YOU HAVE NO ACCESS TO" $2 }' 6>&-

exec 6>&-

Fréquemment votre script peut avoir besoin d'appeler un autre programme ou script qui nécessite une entrée. Le document intégré fournit un moyen d'enjoindre au Shell de lire l'entrée de la source actuelle jusqu'à une ligne contenant seulement la chaîne ad hoc (pas de blancs résiduels). Toutes les lignes lues jusqu'à celle-là sont envoyées comme entrée standard de la commande.

Le résultat est que vous n'avez pas besoin de faire appel à différents fichiers; vous pouvez utiliser les caractères spéciaux du Shell, et c'est plus lisible qu'un flot d'echo:

michel ~> cat startsurf.sh
#!/bin/bash

# Ce script fournit aux usagers un moyen facile de choisir entre plusieurs navigateurs.

echo "Voici les navigateurs WEB de ce système:"
 
# Début du document 'intégré'
cat << BROWSERS
mozilla
links
lynx
konqueror
opera
netscape
BROWSERS
# Fin du document 'intégré'

echo -n "Lequel préférez-vous? "
read browser

echo "Démarrage de $browser, Merci de patienter..."
$browser &

michel ~> startsurf.sh
Voici les navigateurs WEB de ce système:
mozilla
links
lynx
konqueror
opera
netscape
Lequel préférez-vous? opera
Démarrage de opera, Merci de patienter...

Bien que nous parlions de document intégré, il doit être un bloc dedans le script. Voici un exemple qui installe un paquetage automatiquement, même si vous devriez normalement confirmer:

#!/bin/bash
 
# Ce script installe un paquetage automatiquement avec yum.
 
if [ $# -lt 1 ]; then
        echo "Utilisation: $0 package."
        exit 1
fi
 
yum install $1 << CONFIRM
y
CONFIRM

Et voici comment le script tourne. Quand la question « Is this ok [y/N] » apparaît, le script répond « y » automatiquement:

[root@picon bin]# ./install.sh tuxracer
Gathering header information file(s) from server(s)
Server: Fedora Linux 2 - i386 - core
Server: Fedora Linux 2 - i386 - freshrpms
Server: JPackage 1.5 for Fedora Core 2
Server: JPackage 1.5, generic
Server: Fedora Linux 2 - i386 - updates
Finding updated packages
Downloading needed headers
Resolving dependencies
Dependencies resolved
I will do the following:
[install: tuxracer 0.61-26.i386]
Is this ok [y/N]: EnterDownloading Packages
Running test transaction:
Test transaction complete, Success!
tuxracer 100 % done 1/1
Installed:  tuxracer 0.61-26.i386
Transaction(s) Complete