J'ai un fichier bash dont j'ai besoin pour rediriger toutes les sorties vers un seul fichier, le journal de débogage ainsi que vers le terminal. Je dois rediriger à la fois stdout et stderr vers le débogage et le consigner pour toutes les commandes du script.
Je ne veux pas ajouter 2>&1 | tee -a $DEBUG pour chaque commande du fichier. Je pourrais vivre avec | tee -a $DEBUG .
Je me souviens qu'il y avait un moyen de le faire avec quelque chose comme exec 2>&1 .
Actuellement, j'utilise quelque chose comme ceci :
#!/bin/bash
DEBUGLOG=/tmp/debug
exec 2>&1
somecommand | tee -a $DEBUGLOG
somecommand2 | tee -a $DEBUGLOG
somecommand3 | tee -a $DEBUGLOG
mais ça ne marche pas. Quelqu'un a-t-il une solution/peut-il expliquer la cause ?
Réponse acceptée :
Quant à une solution pour rediriger plusieurs commandes à la fois :
#!/bin/bash
{
somecommand
somecommand2
somecommand3
} 2>&1 | tee -a $DEBUGLOG
Pourquoi votre solution d'origine ne fonctionne pas :exec 2>&1 redirigera la sortie d'erreur standard vers la sortie standard de votre shell, qui, si vous exécutez votre script depuis la console, sera votre console. la redirection de canal sur les commandes ne redirigera que la sortie standard de la commande.
Du point de vue de somecommand , sa sortie standard va dans un tuyau connecté à tee et l'erreur standard va dans le même fichier/pseudo-fichier que l'erreur standard du shell, que vous redirigez vers la sortie standard du shell, qui sera la console si vous lancez votre programme depuis la console.
La seule vraie façon de l'expliquer est de voir ce qui se passe réellement :
L'environnement d'origine de votre shell pourrait ressembler à ceci si vous l'exécutez depuis le terminal :
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
Après avoir redirigé l'erreur standard vers la sortie standard (exec 2>&1 ), vous… ne changez pratiquement rien. Mais si vous redirigez la sortie standard du script vers un fichier, vous vous retrouverez avec un environnement comme celui-ci :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Ensuite, la redirection de l'erreur standard du shell vers la sortie standard se terminerait comme ceci :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
L'exécution d'une commande héritera de cet environnement. Si vous exécutez une commande et que vous la redirigez vers tee, l'environnement de la commande serait :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
Ainsi, l'erreur standard de votre commande va toujours dans ce que le shell utilise comme erreur standard.
En relation : ${!FOO} et zsh ?
Vous pouvez réellement voir l'environnement d'une commande en regardant dans /proc/[pid]/fd :utilisez ls -l pour lister également le contenu du lien symbolique. Le fichier ici est l'entrée standard, 1 est la sortie standard et 2 est l'erreur type. Si la commande ouvre plus de fichiers (et la plupart des programmes le font), vous les verrez également. Un programme peut également choisir de rediriger ou de fermer son entrée/sortie standard et de réutiliser , 1 et 2 .