Question sur redirection > et pipe

Bonjour,

Pour comprendre :

> va rediriger la sortie standard de la commande sur la gauche du signe > vers le fichier présenté par le paramètre à droite du signe >.

| va rediriger la sortie de la commande à sa gauche vers l'entrée de la commande à sa droite.

Que se passe t'il dans ce cas ?

Code:

---

ls *.txt>file.txt|cat

---

En testant la commande, le fichier est bien crée mais le cat ne donne pas de résultat.
En théorie en lisant la commande de gauche à droite la sortie de ls est envoyée vers file.txt qui devrait être ensuit être renvoyé vers l'entrée de cat. Comment réagit l’interpréteur dans ce cas ? En apparence, comme la sortie de ls est déjà redirigée, il n'y a pas de redirection vers l'entrée de cat. Est-ce cela ?

Bonjour chrtophe

Citation:

---

Envoyé par chrtophe

Bonjour,

Code:

---

ls *.txt>file.txt|cat

---

En testant la commande, le fichier est bien crée mais le cat ne donne pas de résultat.
En théorie en lisant la commande de gauche à droite la sortie de ls est envoyée vers file.txt qui devrait être ensuit être renvoyé vers l'entrée de cat. Comment réagit l’interpréteur dans ce cas ? En apparence, comme la sortie de ls est déjà redirigée, il n'y a pas de redirection vers l'entrée de cat. Est-ce cela ?

---

Oui , C'est le résultat de la commande "ls *.txt>file.txt" qui est envoyé vers l'entrée de "cat"
en l’occurrence le résultat est "nul" ici (Quand toto va bene) ;)

Un little exemple est mieux qu'un grand discours :ptdr: :oops: : (Avec génération d'une erreur redirigée vers la sortie std (2>&1) qui de fait , deviendra l'entrée du "cat") :aie:

Code:

---

ls *.txt *.yen_a_pas 2>&1 > liste_des_fichiers.txt |cat > le_resultat_de_la_commande_ls

---

Resultat :
le fichier : liste_des_fichiers.txt contient la liste des fichiers "*.txt"
et le fichier : le_resultat_de_la_commande_ls contient

Code:

---

*.yen_a_pas not found

---

Bonjour,

le pipe est pour éviter les fichiers temporaires dans des opérations comme:

Code:

---

1 2 3

$ command1 >/tmp/montmp $ command2 /tmp/montmp $ rm -f /tmp/montmp

---

On préfèrera:

Code:

---

command1 | command2

---

Ce qui montre qu'il faut indiquer le moment où le fichier temporaire putatif doit être utilisé. Par défaut, c'est en fin de commande.

Exemple:
La commande suivante va filtrer les motifs (écrits dans le fichier du même nom) dans le fichier transmis par le pipe:

Code:

---

echo -e "toto\ntiti" |grep -f motifs

---

alors que la commande suivante va filtrer les motifs transmis par le pipe dans un fichier cible:

Code:

---

echo -e "toto\ntiti" |grep -f - cible

---

En effet, le tiret indique qu'on utilise le pipe.

Merci pour vos réponses. argoet, j'avoue que j'ai du mal à suivre. Je me demande l'algo utilisé par le shell pour analyser cela.

Ben c'est simple: c'est la dernière opération exécutée.

Citation:

---

Ben c'est simple: c'est la dernière opération exécutée.

---

Dans le cadre d'un pipe, les opérations sont exécutés en //. Je présumes qu'il faut donc lire la commande de gauche à droite ...

salut,

Citation:

---

Envoyé par chrtophe

j'avoue que j'ai du mal à suivre. Je me demande l'algo utilisé par le shell pour analyser cela.

---

si tu fais référence à l'expression d'argoet de la forme commande 2>&1 > fichier | cat, il faut bien comprendre que 2>&1 ne fusionne pas les deux sorties mais applique simplement à la sortie 2 la configuration de la sortie 1, c'est à dire qu'on configure la sortie 2 pour être un "stdout", lequel sera transféré à cat par le pipe, tandis qu'on envoie la sortie 1 directement dans un fichier

Citation:

---

Envoyé par chrtophe

Je présumes qu'il faut donc lire la commande de gauche à droite ...

---

OUI! Les deux commandes suivantes ne sont pas équivalentes:

Code:

---

1 2	$ ls *.txt *.yen_a_pas > liste_des_fichiers.txt 2>&1 |cat > le_resultat_de_la_commande_ls $ ls *.txt *.yen_a_pas 2>&1 > liste_des_fichiers.txt |cat > le_resultat_de_la_commande_ls

---

Décortiquons:

1. • La sortie standard est redirigé vers un fichier.
   • La sortie d'erreur est redirigé comme la la sortie standard, donc dans un fichier.
   • Il n'y a plus de sortie. Donc le pipe ne reçoit rien.
   
   Au final, un fichier contiendra le résultat et les erreurs alors que l'autre sera vide.
2. • La sortie d'erreur est redirigée comme le standard (par exemple vers l'écran)
   • la sortie standard est redirigée vers un fichier.
   • le pipe reçoit la sortie standard, c'est à dire les messages d'erreurs.
     Au final, le premier fichier aura les résultats et le second fichier aura les erreurs.
   
   

Flodelarab,

Citation:

---

Décortiquons:

La sortie standard est redirigé vers un fichier.
La sortie d'erreur est redirigé comme la la sortie standard, donc dans un fichier.
Il n'y a plus de sortie. Donc le pipe ne reçoit rien.

---

Je comprends par ceci que la sortie standard étant redirigée, il n'y a plus de "sortie standard", donc le pipe ne reçoit rien. Est-ce bien cela ?

Citation:

---

il n'y a plus de "sortie standard"

---

Elle existe toujours mais personne ne lui parle. De plus, personne ne pourrait lui parler car on a perdu la référence. Si on imagine un cas tordu où il faudrait sauvegarder la référence, on pourrait ouvrir des canaux de numéro 3, 6 ou 7 etc pour garder la mémoire de ce descripteur de "sortie standard".

Merci pour les réponses. Je clos le sujet.