Discussion :

[AralVor]

Bonjour,

J'ai un script qui fait des sorties standards vers un fichier de log
J'ai aussi un fichier "trace" qui est en fait un log mais beaucoup plus verbeux

J'aimerais le rendre plus joli, et quand j'ai des occurences par exemple de "echo "le script démarre !" j'aimerais en une ligne pouvoir rediriger la sortie standard de cette commande vers deux fichiers

typiquement qque chose qui serait comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "le script démarre, il est "`date` >> $LOG >> $TRACE

mais bon ça ne marche pas évidemment

j'ai fouillé un peu sur le net mais rien trouvé, ça vous dit quelque chose ?

D'avance, merci

[N_BaH]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "le script démarre, il est $(date)" | tee -a $TRACE $LOG &>/dev/null

mais, ça fait un peu bricolage... parce que tee est censé servir pour lire sur l'entrée standard et écrire sur la sortie standard. Or, ici, on redirige la sortie standard vers /dev/null (et donc l'affichage ne se fait pas à l'écran).

bref, ça me parait bizarre... existe-t-il une meilleure solution ?

[AralVor]

effectivement on bidouille avec le /dev/null, mais bon, pour éviter de recopier les mêmes lignes en doubles, c'est déjà pas si mal (même si j'aurais préféré éviter passer par une pipe pour tout ça)

merci pour ta solution !

PS : le &> ça veut dire que tu rediriges toutes les sorties possibles à cet endroit? ça évite de faire 1> 2>... etc?

[N_BaH]

Tout à fait.

man bash a dit :

Il y a deux formes pour rediriger les sortie standard et sortie d’erreur standard :

&>mot
et
>&mot

La première des deux formes est préférée. Ceci est sémantiquement équivalent à

>mot 2>&1

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "le script démarre, il est $(date)" | tee -a $TRACE $LOG &>/dev/null

mais, ça fait un peu bricolage... parce que tee est censé servir pour lire sur l'entrée standard

Comme 95% des programmes Unix. Prenons par exemple grep. grep a pour but d'extraire de l'entrée standard des lignes contenant un motif. Il se trouve que si on passe en second paramètre un fichier, grep considère ce fichier comme celui contenant les infos à extraire mais ce n'est pas obligatoire. Par défaut, grep prend ses infos dans l'entrée standard. De même pour cut, cat ou wc...

et écrire sur la sortie standard.

Ben là aussi, c'est le cas de 95% des programmes Unix. Ils écrivent leurs infos sur la sortie standard. Et c'est grâce à ce comportement universel qu'on peut assembler des commandes simples via des pipes pour créer des traitements plus complexes.

Or, ici, on redirige la sortie standard vers /dev/null (et donc l'affichage ne se fait pas à l'écran).

C'est là aussi fait pour ça. Ainsi, quand tu crées un programme, tu n'as pas besoin de te demander si c'est pour être exécuté en tant qu'entité indépendante ou bien s'il est là pour être intégré dans un ensemble plus vaste et te demander quoi faire de tes infos. Tu les bennes sur stdout sans te poser de question et si celui qui utilisera ton programme n'a pas envie de les avoir, il les redirigera vers /dev/null.
D'ailleurs, on utilise parfois des programmes simplement parce qu'ils existent sans utiliser les valeurs qu'ils donnent. Exemple: en Bourne Shell de base, l'option "-e" n'existe pas pour la commande "test". Ainsi il est impossible de vérifier si un fichier existe en Bourne Shell via "test -e". Une des méthodes les plus simples pour pallier ce manque peut-être la suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ls fichier 1>/dev/null 2>&1 && echo "fichier existe" || echo "fichier n'existe pas"

On se sert simplement du fait que ls trouvera ou ne trouvera pas le fichier (et renverra aussi un statut vrai ou faux) pour dire si le fichier existe ou n'existe pas mais on ne se préoccupe absolument pas de ce que "ls" affiche.

bref, ça me parait bizarre... existe-t-il une meilleure solution ?

Non. Tu as fait ce qu'il y a de mieux. Utilisé des programmes répondant à ton besoin en te débarassant de ce qu'il y a en trop. Plus tard, quand tu feras des scripts plus important, tu auras le choix entre 2 programmes qui font presque pareil. La meilleurs solution alors sera d'utiliser le programme le plus efficace (le plus rapide, le plus petit, le moins gourmand, etc) du lot pour résoudre ton problème et de même, si le programme te donne des infos inutiles, jette les.

effectivement on bidouille avec le /dev/null

On se sert proprement du périphérique /dev/null qui a été conçu pour ça !!!

...(même si j'aurais préféré éviter passer par une pipe

Bof... quand l'occasion se présente faut pas la rater

UN fichier de type "pipeline" donc en abrégé UN pipe !!! Sinon on pense à autre chose...

pour tout ça)

"tout ça" ??? Plus tu auras de traitements complexes plus tu en feras des pipes (oui oui, c'est toi qui les fait donc vaut mieux bien écrire pour pas qu'il y ait pas d'ambigüité sur ce à quoi on pense). Et quand l'algo deviendra très complexe, tu ne pourras même plus te contenter de pipes mais faudra que tu programmes des traitements en conséquence avec des conditionnelles if...fi et des boucles do...done alors sois content d'avoir pu résoudre ton problème avec simplement un pipe...