Le ven 30 jun 2006 08:25:25 CEST, Marc TERRIER <marc.terrier@???> a
écrit :
> J'aurais cru naïvement que "# ma_commande 2>&1 >fichier.log" avait pour effet de
> rediriger stderr dans stdout, puis de mettre *le tout* dans le fichier de log.
> Cela me paraissait logique, et simple. Manque de bol, c'est pas comme ça que ça
> marche.
Pour le shell, les numéros, 2, 1 (valeur par défaut pour >) sont des
indices de flux qui désignent un fichier ouvert. Le truc pour
comprendre, c'est que chaque commande de redirection effectue son
changement *dans le contexte des redirections déjà effectuées*, mais
pas de celles à venir ! Dans ton exemple ci-dessus, lorsque le shell
voir '2>&1', il reconfigure le flux n°2 pour utiliser le même
fichier que le flux n°1, c'est-à-dire à ce moment là, la
sortie standard de ton terminal (/dev/stdout).
Ensuite, il interprète '>fichier.log' et redirige le
flux n°1 vers ton fichier 'fichier.log', mais le flux n°2 n'est pas
touché !
En revanche, dans "# ma_commande >fichier.log 2>&1",
le shell commence par rediriger le flux n°1 sur ton fichier
'fichier.log' (en lieu et place de /dev/stdout). La seconde commande
redirige le flux n°2 sur le même fichier que celui du n°1, c'est à dire
le fichier.
Pour l'analogie, plutôt que les entonnoirs, je penserais à des
aiguillages...
Fred.
