Salut,
 
Hier, je ne comprenais pas comment utiliser les tubes nommés mais grâce à Threep, tout va bien maintenant.    
 
Aujourd'hui, c'est un peu la suite du problème, avec les substitutions de commandes qui - si j'ai bien compris - font le même travail que les tubes nommés.    
 
voici ce que j'ai pu lire : syntaxe d'une substitution de commande :
<(commande) OU >(commande)
 
Ce que je veux faire :
je demande au shell bash de trouver tous les fichiers .txt qui contiennent le mot "test" dans le chemin d'accès /home
 
la solution classique qui marche :
find /usr/ -name *.txt | xargs grep -l "test"
affichage du bash après validation :
/home/gaia/essai.txt
(c'est le seul fichier à contenir le mot "test", donc ça marche !)
 
voici la solution qui marche pas (utilisation d'une substitution de commande) :
xargs grep "test" <(find /home -name *.txt)
le curseur se positionne sur un début de ligne blanche et je suis obligé d'utiliser Ctrl + C pour arrêter.
 
autre solution qui marche pas et qui donne une réaction du bash que je ne comprends pas : j'ajoute cat <(ensemble précédent)
cat <(xargs grep "test" ) <(find /home -name *.txt)
le bash ne bloque pas et écrit 2 lignes :
grep: (standard input): Input/output error
/home/gaia/essai.txt
Je ne comprends pas la première ligne. Quant à la deuxième ligne, elle témoigne de la "réussite" de la commande : le fichier essai.txt contient bien le mot "test".
 
merci de votre aide  

erratum : je viens de retaper les commandes et la finalement, cela ne marche pas du tout, même avec "cat <"

conclusion : seule la première méthode fonctionne
(c'est à dire :
find /usr/ -name *.txt | xargs grep -l "test"
)

cat <(xargs grep "test" ) <(find /home -name *.txt)  
 
Ca n'a aucun sens ca  
en gros, tu veut faire comme le pipe, mais a l'envers  
Desolé de ne pas comprendre l'interet de la chose

cat <(xargs grep "test" )
 
En gros ce que je comprend de ca :
Tu veut faire lire par cat le resultat (stdout) de grep qui n'a pas encore été executer...
 
Je crois que tu a oublier que le shell etait un language de script
 
Il execute les commandes dans l'ordre une par une en attendant que la premiere ai finnit pour lancer la suivante et ainsi de suite

 
Tu as tout à fait raison ! Je ne comprends rien à cette syntaxe :
"<(commande)"
et du coup, j'ai écrit des trucs qui ne tiennent pas debout.
 
On va faire beaucoup plus simple :
 
cat <(ls)
là, le bash comprend comment traiter la ligne
 
par contre :
less <(ls)
donne le message d'erreur suivant :
/dev/fd/63 is not a regular file (use -f to see it)
 
Pourquoi ?  

cat <(ls)
 
Premiere commande = cat
seconde commande = ls
 
La premiere tente de lire la deuxieme
Chose impossible puisque la deuwieme n'a pas encore pus etre executer vu que la premiere attend sa reponse
 
Cette ligne pour donner le resultat attendu devrait s'ecrire  
ls > liste && cat liste

Aie, je ne comprends rien !    
 
En fait, je lis une doc mais tout ce qui tourne autour des tubes, des redirections et des substitutions de commande, je trouve ça un peu dur.
 
Je crois que je m'explique comme un pied.    
Le plus simple, c'est peut-être de faire un copier-coller de la doc reprenant le passage que je ne comprends pas.
 
attention, il y a quelques lignes :
 
---------------------------------------------------------------
Le shell fournit une substitution permettant d'obtenir des fonctionnalités similaires à celles fournies par les pipes nommés. Cette substitution est la substitution de commande.  
 
La syntaxe utilisée par les substitutions de commandes est similaire à celle des redirections classiques :  
 
<(command)
ou :  
>(command)
où command est la commande à substituer.  
 
La première syntaxe permet de lancer une commande en arrière-plan en redirigeant son flux standard de sortie vers un descripteurs de fichiers du shell. Le résultat de cette substitution est le nom du fichier /dev/fd/n permettant de lire les données écrites par la commande dans ce descripteur de fichier. En pratique, on utilise donc cette substitution en lieu et place d'un fichier d'entrée pour une commande normale. La deuxième commande permet de lancer également une commande en arrière-plan, mais en redirigeant le flux d'entrée standard de cette commande cette fois. Il est alors possible de fournir les données nécessaires à cette commande en écrivant dans le fichier /dev/fd/n dont le nom est fourni par le résultat de la substitution.  
 
Ces deux commandes permettent donc de simplifier l'usage des pipes nommés, en évitant d'avoir à créer un fichier de tube nommé manuellement et d'avoir à lancer les deux commandes devant se servir de ce tube pour communiquer. Ainsi, la commande suivante :  
 
 
cat <(ls)
 
est fonctionnellement équivalente à la série de commandes suivante :  
 
mkfifo /tmp/lsfifo
ls > /tmp/lsfifo
cat /tmp/lsfifo
rm /tmp/lsfifo
 
Les substitutions de commandes sont donc nettement plus pratiques et plus sûres, car elles n'imposent pas la création d'un fichier de pipe nommé dont le nom peut être choisi arbitrairement.
"
--------------------------------------------------------------
 
Voilà, je ne comprends pas ce passage et que le shell exécute avec un cat <(ls)    
 
Merci de votre aide (dur d'être un newbie sous Linux, mais encore plus dur de ne pas être bon en programmation   , même si ça ressemble à une ligne ridicule de quelques lettres !!! (cat <(ls))

Ben ecoute, je ne suis peut etre pas encore trop avancer dans ce secteur, mais le seul pipe que je connaisse, c'est "|" qui lit stdout pour le renvoyer sur stdin a la commande suivante
cat blabla.txt | grep test est un bon exemple
 
Alors que les "<>" redirigent l'informations vers un fichier voir un pipe style
 
./configure > /dev/null 2> erreurs.log
 
Les informations sans importances seront ballancer dans un pipe direction le nirvana (/dev/null) et les erreurs, dans le ficher erreurs.log
 
Quand au <, je ne connais pas sa fonction

Si, je me souviend d'une utilisation de "<"
 
dans un script pour passer des commandes a un programe
style programme <<- EOF
la
tu
tape tes commandes
et tu finit par EOF
pour lui faire comprendre que c'est finnit
 
En pratique, ca donne ca (un script pour uploader une image issu d'une webcam a intervalles regulieres) :
 

 
Faut faire gaffe aux espaces en bash !

et heu, sinon grep -rs test spa plus court ?

Ouah,
lithium, e_esprit, minusplus, merci de vos réponses.
Même si je ne comprends toujours rien, vos réponses m'encouragent à continuer (oui, je suis découragé   )
 
Merci beaucoup, vraiment.
 
Je vais essayer de rebondir sur vos réponses, pour essayer d'avancer
 
* post de lithium
lithium, tu sais à quoi sert le signe > mais tu vois moins à quoi peut servir le signe < ?
(merci pour ton exemple avec <, bien que je ne le comprenne pas encore : je connais très très peu de commandes pour le moment)
 
Je pense être capable de fournir des exemples très simples illustrant l'utilité de < et > ,qui sont des opérateurs
assurant le transfert de flux de données.
 
exemple avec > :
ls >essai.txt
la commande lance ls et lui demande de renvoyer son flux de sortie dans essai.txt plutôt que de le renvoyer sur l'écran.
 
exemple avec < :
rm -i essai.txt <ordre.txt
la commande demande à rm de supprimer le fichier essai.txt et le -i indique que rm demandera à l'utilisateur une confirmation pour suppression Y/N (Oui ou Non).
Or, j'ai créé un fichier ordre.txt qui contient cette info (ce fichier ordre.txt contient une lettre ! c'est le "n".
Ainsi, la lettre n est balancée dans le flux d'entrée de rm, et quand rm demande à l'utilisateur de confirmer, il va chercher son info dans ordre.txt au lieu de la recevoir du clavier.
Cela n'a pas pour autant redirigé le flux de sortie de rm, et on voit la question qui est posée, sans pouvoir y répondre puisque la réponse a été immédiatement fournit grâce à ordre.txt
 
Pour ne plus voir la question, il suffit d'écrire :
rm -i essai.txt 2>/dev/null <ordre
là, on renvoie le flux d'erreur sur /dev/null
 
* post de e_esprit
cat< (ls)  
=> marche pas  
cat < (ls)  
=> marche pas  
cat <(ls)  
=> MARCHE
 
Oui, j'avais remarqué mais je ne comprends pas encore pourquoi.
mais de toutes façons, je ne comprends rien à cette commande.  
 
Voici ce qui est écrit dans la doc que je lis :
cat <(ls)
 
est fonctionnellement équivalente à la série de commandes suivante :  
 
mkfifo /tmp/lsfifo
ls > /tmp/lsfifo
cat /tmp/lsfifo
rm /tmp/lsfifo
 
(allez comprendre ce que viennent faire les tubes nommés la dedans... dur-dur)
 
* post de minusplus
minusplus, je n'ai pas regardé à quoi correspondaient les options de grep que tu mets dans ta commande, mais ça marche !
(mais je ne comprends pas ce que ça fait et ce n'est pas grave!)
 
Sinon, je suis toujours bloqué dans ma compréhension des redirections, des tubes et des substitutions de commandes.
 
Le plus simple, c'est déjà de revenir sur le premier truc qui m'a bloqué. Ce truc n'a rien à voir avec la commande cat <(ls) (qui m'a achevé)
Il concerne les redirections. (< et > ).
 
Parce que même si j'ai donné à mon tour des exemples que je comprends, il y a quelque chose que j'aimerai savoir sur les redirections :
y a-t-il un moyen de savoir comment une commande se comporte  quant on lui injecte un flux d'entrée ou quand on lui demande de renvoyer un flux de sortie ?
 
Je m'explique :
si je fais un  
rm -i essai.txt <ordre
le flux d'entrée agit sur rm pour alimenter une confirmation
(à condition que ordre.txt contienne juste y ou n).
maintenant, si je veux fournir à rm un nom de fichier à supprimer, en utilisant une redirection, comment je fais ?
Je ne peux pas me servir du flux d'entrée de rm puisqu'il n'est pas fait pour ça. Encore faut-il s'en rendre compte.
 
Par contre, ce qui n'est pas possible avec rm est possible avec less :
less <essai.txt me permet de visualiser le fichier essai.txt  
 
Pourtant, je m'attendais à ce que less reçoivent une info comme la touche 'q' pour quitter après visualisation du fichier en paramètre d'entrée.
Mais less ne fonctionne pas comme rm...
Savez-vous comment on peut faire pour savoir ce qu'attend une commande en flux d'entrée ? Sinon, je ne vois pas comment utiliser les redirections correctement car les commandes ont des comportements différents.
 
Avec l'aide de man et de info, on a le synoptique qui permet de savoir dans quel ordre il faut écrire la commande, entre les fichiers et les options, par exemple.
Mais on n'a pas d'infos sur ce qu'elles acceptent comme flux d'entrée ou comment elles formatent le flux de sortie    
 
Bon, ce sera tout pour ce soir.
Merci à tous pour le temps que vous passez à me lire.
   

Je crois que :
> = stdout vers un autre out (un ficher ou pipe)
< = subistitu stdin vers stdin
| = stdout vers stdin

Pfiou quel post !!!
Je vais essayer de repondre ce a quoi je peux...
 

Mais y a pas de quoi !

Merci e_esprit
 
ça me semble plus clair maintenant.
Merci aussi pour tes copies de man less et man cat. Finalement, les infos s'y trouvaient et j'ai lu trop vite (parce que c'est anglais et parce que je m'attendais à trouver ça dès le début, avec le synoptique de la commande.
 
Par contre, pour cat <(ls), je ne comprends la syntaxe.
 
cat <(ls), ça marche
more <(ls), ça marche
less <(ls), ça marche pas et ça inscrit le message d'erreur suivant :
/dev/fd/63 is not a regular file (use -f to see it)
 
C'est bizarre, non ?    

Je viens de tester les mkfifo trucs bidules...
 
Et ca fait bien la meme chose...
 
Ma conclusion : less ne supporte pas de travailler sur un pipe, par defaut il le prends pour un fichier, mais comme c'est un type de fichier special... ca plante (/tmp/fifols is not a regular file (use -f to see it))
 
Et donc...
 
less -f <(ls)
 
ca marche !!! (bah oui, les messages d'erreur faut les lire !   )

j'y vois de plus en plus clair    
 
Merci e_esprit
 

 
Oui, bien sûr    
Je suis déjà à fond dans les docs et ton message m'aide beaucoup même si peut-être, j'avais les moyens de trouver tout seul.
Ca fait un mois que je suis sur cette doc pour m'initier et je sature.    et surtout j'étais découragé    
 
Maintenant que ça va mieux, j'aimerais en finir avec ces commandes que je ne comprenais pas et que je comprends mieux :
 
cat <(ls) ça marche
more <(ls) ça marche
less <(ls) ça marche pas car il faut ajouter -f
 
pourtant :
ls | cat  ça marche
ls | more  ça marche
ls | less  ça marche aussi et sans le -f
 
c'est bizarre, ça    :
less <(ls) ça marche pas car il manque -f
ls | less  ça marche, y a pas besoin d'ajouter  -f
 
ça voudrait dire que le tube non nommé (dont l'opérateur est | )n'utilise pas les descripteurs de fichiers   (puisque less n'est pas gêné)
 
Je pensais qu'il y avait un lien entre les descripteurs de fichier et la gestion des flux d'entrées/sorties/erreurs.
 
Bon, pour être honnête, la notion de descripteur de fichier n'est pas clair non plus dans ma tête, je m'en rends compte à cause de ces stupides commandes ... less -f <(ls) et ls | less

un | c'est stdin : un descripteur de fichier tout ce qu'il y a de classique
 
un <() émule un fifo qui n'est pas un fichier standard.  
 
ça me semble logique...

 
Oui, OK
 
je m'embrouille, c'est dingue...    
Merci de me remettre sur les rails.  
 
Mais je repose cette question : pourquoi y a-t-il besoin de descripteurs de fichiers pour faire transiter l'info dans le cas d'un tube ?    
Quel différence avec un fichier "classique" qui stockerait directement les infos du flux de sortie de ls ?   ,
 
Pouvez-vous me donner une petite réponse faite à mon petit niveau ?

Un tube, tu peux le lire qu'une fois.
Tu ecris, il contient des choses, tu le lis, alors tout ce que tu as lu ne s'y trouve plus. C'est une file d'attente quoi...

Merci à tous pour votre aide.    
 
Maintenant, je suis regonflé à bloc et j?ai essayé de faire une synthèse sur tout ça : les redirections, les tubes, les tubes nommés et les substitutions de commandes.
 
Je vous le soumets pour savoir si je n?ai pas écrit de bêtises et pour savoir si j?ai bien compris vos explications. Par ailleurs, il y a une ou deux petites questions qui me sont venues à l?esprit en rédigeant ce document, notamment sur les fifos.
 
Merci à tous, en particulier à e_esprit mais aussi à tous les autres que je n'oublie pas de mentionner ci-dessous dans certains points de ma synthèse car rien n'aurait été possible sans vous tous !
 
 
Voici mes notes maintenant :
 
 
1) Il est important de ne pas perdre de vue la limite des opérateurs
On peut rediriger des flux grâce à plusieurs opérateurs, mais tous ne sont pas capables des mêmes choses :
 
1a) les opérateurs (dits "de redirection" ) "<" et ">"
Ces opérateurs redirigent des flux grâce aux descripteurs de fichiers.
Ils sont là pour diriger un flux d'une commande vers un fichier ou d'un fichier vers une commande.
Ils ne peuvent pas diriger un flux d'une commande vers une commande. Ceci est logique à cause de la syntaxe.
En effet, la syntaxe utilisant ces opérateurs "<" et ">" ne permet pas d'indiquer au shell comment il doit considérer les chaînes de caractères successives qui constituent l'expression complexe (s'agit-il de commandes ou de fichiers ?).
Je l'ai compris grâce aux explications de Lithium qui a insisté sur le fait que le shell lit les instructions de gauche à droite et ce que cela a pour conséquence.
Impossible d?avoir une ligne de commande du genre : fichier < commande.
Ainsi :
- la partie de gauche sera interprétée comme une commande.
- la partie de droite avec les signes "<" et ">" sera interprétée comme fichier de données, lié à la commande.
 
Il est normal que la syntaxe des opérateurs de redirections ne permette pas de rediriger un flux d'une commande vers une autre commande. Il faut absolument passer par un tube qui joue un rôle de file d'attente.  
C'est un intermédiaire obligé : le flux de sortie d'une commande transmet à une vitesse donnée des infos que le flux d'entrée de la commande réceptrice peut traiter plus ou moins vite.
Cela, je l'ai compris grâce aux explications de e_esprit .
 
1b) l'opérateur  (dit "tube" ) "|"
Cet opérateur redirige des flux grâce aux descripteurs de fichiers.
Le tube permet de diriger un flux d'une commande vers une commande. Il complète ainsi ce qui n'était pas possible avec les opérateurs de redirections.
 
1c) le tube nommé
Un tube nommé permet de rediriger des flux grâce aux fichiers spéciaux appelés fifos.
Le tube nommé permet de faire transiter un flux d'une commande vers une commande.
Cependant, je ne vois pas comment l'utiliser correctement sur une seule session bash.
Mais je sais le faire à l'aide de 2 terminaux virtuels différents, grâce à la réponse de Threep qui m'a bien aidé dans mon topic précédent "Comment créer un tube nommé sous Linux avec le shell bash ? "
Donc, j'utilise 2 terminaux virtuels différents :
- l'un pour créer le fifo et lui envoyer un flux d'entrée
- l'autre pour recevoir le fifo dans la commande réceptrice.
 
Exemple :
écriture dans le terminal 1 :
mkfifo fifo
ls > fifo
écriture dans le terminal 2 :
cat < fifo
 
Ma question :
Comment terminer l'opération dans le terminal 1 sans faire appel à un deuxième terminal virtuel ?
En effet, suite aux instructions (mkfifo fifo) et (ls > fifo), le curseur de la ligne de commande du bash se place sur une nouvelle ligne blanche et je ne vois pas comment faire à partir de là.
 
Il y a une doc que je lis et qui me sert de guide depuis que je me mets à Linux,
(merci à Pipomolo - un autre forumeur de hardware - pour l'URL de cette doc. Il me l'a donnée il y a un an et je la lis seulement maintenant, parce que je n'avais pas le temps. Enfin, je me lève le matin à 6H pour avoir le temps de lire pendant une heure ; et le soir j'essaie aussi de lire une heure ou deux !  
Mais bon, heureusement que vous avez été là en début de semaine pour me remonter quand j'étais découragé ; j'essaie d'ouvrir mon horizon professionnel et c'est pas évident. Merci à tous ! Fin de la petite parenthèse).
Donc, sur cette doc, il est écrit :
"Il est possible de créer manuellement des tubes en leur donnant un nom, et de les utiliser à posteriori dans plusieurs commandes. Ces tubes constituent ce que l'on appelle des tubes nommés."
Ce qui m'interpelle, c'est le mot "plusieurs" . Pouvez-vous m'aidez à comprendre ça ?
 
1d) la substitution de commande (c'est comme ça que ça s'appelle dans ma doc, en tout cas)
La substitution de commande permet de faire la même chose qu'avec un tube nommé sauf que les flux d'entrée et de sortie sont immédiatement donnés, donc la commande peut exécuter immédiatement le travail car toutes les instructions sont sur la même ligne.
Exemple :
cat <(ls)  (je m'en souviendrai longtemps de cette commande que j'ai enfin comprise !!! , suite à vos explications sur les redirections, les tubes, les descripteurs de fichiers et les fifos !!! )
 
 
2) Il est très important de se souvenir que chaque commande réagit différemment et n'utilise pas les flux d'entrée et de sortie de la même façon.
ainsi :
le flux d'entrée de rm -i sert à recevoir une information de confirmation de suppression (ce flux ne sert pas à alimenter rm en fichiers à supprimer)
le flux d'entrée de less sert à recevoir des noms de fichiers à lire (contrairement à rm, le flux d'entrée de less sert bien à alimenter less sur les fichiers cibles à lire)
Cela, je l'ai compris tout seul mais e_esprit m'a beaucoup aider à savoir comment faire pour connaître les réactions des commandes : il suffit de lire la doc !
(oui, c'est évident quand on comprend très bien l'anglais et quand on ne sature pas à cause de tout un tas d'autres choses qu'on ne comprend pas au même moment). Merci e_esprit !
 
 
3) Ma conclusion
 
En résumé, tout est logique, il y a :
3a) les opérateurs de redirections "<" et ">"
3b) les tubes "|"
3c) les tubes nommés (mkfifo + autres commandes derrières pour les utiliser)
3d) ce que ma doc appele "les substitutions de commande" et que j'ai envie d'appeler "condensé sur une ligne des commandes d'un tube nommé"
 
Je me demandais :
pourquoi y a-t-il autant d'opérateurs pour les redirections de flux ?
 
Tout simplement parce que ces différents opérateurs ne sont pas du tout chargés de réaliser la même chose d'un point de vue système :
Qu'est ce qui les différencient ?
 
3a et 3b se démarquent de 3c et 3d : les premiers utilisent les descripteurs de fichiers tandis que les seconds utilisent les fifos.
Cela, je l'ai compris grâce à la commande less qui ne peut pas lire les fifos, grâce à e_esprit et grâce à minusplus  
 
Ils restent à différencier 3a de 3b et aussi 3c de 3d.
 
Dans le cas de 3a, les files d'attentes n'ont aucun sens puisque les fichiers sont des éléments "passifs".
Dans le cas de 3b, les files d'attentes possibles grâce aux tubes sont indispensables car 2 commandes vont chacune à leur propre vitesse.
 
On remarque enfin que ce qui différencie 3c et 3d est une exécution immédiate dans le cas de 3d alors que 3c m'interpelle encore.
Sinon, qu'est ce qui les différencient vraiment ? À voir grâce à vos explications !
 
 
Une dernière question :
quel est l'intérêt d'utiliser les fifos plutôt que des descripteurs de fichiers dans le cas d'une redirection de flux entre 2 commandes ?
en effet, quelle différence entre :
ls | cat
et
cat <(ls)
L'une utilise les descripteurs de fichiers tandis que l'autre utilise les fifos.
 
La commande time ne m'a pas permis de savoir ce qui est le plus rapide. Il faudrait un exemple plus complexe que cat et ls.
À votre avis ?
En tout cas, voici une info intéressante de ma doc qui permet de faire la différence entre les descripteurs de fichiers et les fifos :
"La quantité de données en transit dans les fifos est souvent très réduite, ce qui fait que ces données sont toujours placées dans la mémoire cache du système.
Donc, ça voudrait dire que les descripteurs de fichiers, c'est moins bien que les fifos, pour transférer un flux d?une commande vers une autre commande ?
Par ailleurs, je sais que les fifos ne sont pas utilisables avec certains systèmes de fichiers comme FAT.
Ne me dites pas que les tubes (utilisant les descripteurs de fichiers) ont été créés en plus des tubes nommés (utilisant les fifos) dans le simple but d'assurer une compatibilité avec les systèmes de fichiers du genre FAT ?
Il y a bien une autre raison qui fait qu'on utilise les fifos dans certains cas et les descripteurs de fichiers dans d'autres cas ?
 
Et voilà !
Ce sera tout pour ce soir !  

Ce que je comprend c'est qu'il faut utiliser | quand la commande qui va recevoir les données sait lire sur stdin, et dans le cas ou cette commande ne sais pas lire sur stdin, tu utilises <(...)
 
Par exemple, gunzip ( pour les .gz ) sais lire sur stdin, mais unzip ( pour les .zip ) ne sait pas.

 
tu es sûr que c'est unzip ?
le bash me dit
bash: unzip : command not found
Merci pour ta réponse.
 
sinon, je me rends compte que j'ai écris quelques bêtises hier soir dans mon long post    
J'en ai marre de tout ça ...
 
Je pense que ma conclusion est fausse. Reprenons-la.
 

les seconds utilisent les fifos mais ils se basent aussi sur les descripteurs de fichiers, tout comme les premiers, non ?
 

 
Ce n'est pas ça ! Ce que la commande less ne peut pas lire, ce sont les descripteurs de fichiers ! Lire un fifo, less en semble capable d'après mes tests. En conséquence, je ne comprends plus ce que je croyais avoir compris depuis le post de minusplus (ras le bol !).
 
Ainsi, la fin de mon post n'a plus de sens :  
 

 
encore une fois je ne crois plus que les fifos remplacent les descripteurs de fichiers. Cela n'a rien à voir
 
Poursuivons mon post d'hier :
 

 
encore une fois, je dois me planter...
 

encore une fois, c'est pas bon ce que j'ai écris. Les descripteurs de fichiers et les fifos ne s'opposent pas. Je pensais qu'on utilisait soit l'un, soit l'autre. C'est du délire ce que je croyais.
 
J'ai écrit des trucs faux, je m'en rends compte, il y en a peut-être plein d'autres. (non y en a pas d'autres, soyons optimistes   )
 
Heu... y en a peut-être d'autres quand même. Pouvez-vous m'aider    ?
 
Je voudrais reprendre le post de e_esprit que je remercie pour son aide. Je ne le comprends plus (j'avais lu trop vite).
 
e_esprit, voici un morceau d'un post que tu as écrit :
 

 
tu es sûr que ça plante avec l'utilisation de fifos ?
 
j'ai essayé après avoir créer un fifo :
cd /tmp
mkfifo fifo
ls > fifo
puis dans un deuxième terminal :
less < fifo
et ça marche très bien.
 
les fifos ne sont dont pas en cause, qu'en pense-tu ?
 
Par contre,
less <(ls)
donne le message d'erreur suivant :
/dev/fd/63 is not a regular file (use -f to see it)
less ne peut pas lire le descripteur de fichier. Le problème ne vient pas des fifos, apparemment mais des descripteurs de fichiers.
 
ls | less, ça marche.
 
Pourtant, le "|" utilise stdin et stdout, ce qui signifie qu'il utilise les descripteurs de fichiers, non ?
 
Pourtant, less n'est pas gêné.
 
après ton post, minusplus m'a répondu :
 

 
en partant du fait que less est gêné par les descripteurs de fichiers, je ne vois pas pourquoi
ls | less
ça marche et qu'on est pas obligé d'écrire :
ls | less -f

 
j'en ai marre de tout ça. Mais si je ne comprends pas ces bases, à quoi ça sert que je continue ?  

Si tu n'as pas installé unzip, tu ne risques pas de pouvoir l'utiliser ...

OK, merci
 
(ne vous marrez pas, mais je ne sais pas encore installer correctement des packages et choisir des programmes).
Je suis sous Debian
D-select semble très puissant mais j'ai souhaité m'attaquer au bash avant.
 
J'espère que je ne vous assome pas avec mes posts, à cause de mon petit niveau.
 
Merci à tout ceux qui m'aident.

apt-get install ton-appli
sinon dpkg -i ton-paquetage.deb

apt-cache search lenomprobableduprog
là il te pond une liste de pkg avec une description sommaire et t'as plsu qu'a faire apt-get install lepkg

Mon topic s'appelle "substitution de commande" (c'est comme ça que c'est intitulé dans la doc de Christian CASTEYDE, que vous connaissez peut-être ; elle est indiquée en lien sur hardware).
 
Cependant la doc française de man bash parle de "substitution de processus" et non de "substition de commande"   Je viens de le découvrir.
 
Vous le savez, je me pose des questions sur ce sujet depuis un certain temps.
 
Pour ceux qui prendrait le topic en cours de route, voici mon problème :
je ne comprenais pas la commande suivante :
cat <(ls)
 
grâce aux explications de quelques forumeurs sympas, ça va mieux.
 
Mais je n'ai pas tout compris et mes derniers posts assomants (car longs mais le plus explicatif possible pour vous aider à m'aider   ) sont restés sans réponse.
 
Ce n'est pas grave, vous m'avez déjà beaucoup aidé    
 
Je suis resté frustré quand même de cette histoire.
 
Résumons l'essentiel pour faire repartir mon petit topic (si le coeur vous en dit   )
 
d'après la doc man bash française,
les substitutions de processus utilisent la syntaxe suivante :
<(liste) ou >(liste)
où liste est une liste de processus
 
par exemple :
cat <(ls)
ou bien encore (pour faire un autre exemple très simple qui illustre bien le principe de liste de processus) :
cat <(ls /usr; ls /etc)
 
Voici un copier-coller d'une ligne du man bash :
"La liste de proces­sus est exécutée avec ses entrées et sorties connectées à une FIFO ou à un fichier dans /dev/fd"
 
Vous avez remarqué ? Il y a un mot de 2 lettres dans ce copier-coller qui est :
"ou"
 
le "ou" en langue française (pas informatique !) peut  
être inclusif ou exclusif suivant le contexte.
D'où ma question :
C'est quoi comme "ou" celui-là ?
 
Pour info, lorsque je tape la commande
less <(ls)
j'ai le message d'erreur suivant :
/dev/fd/63 is not a regular file (use -f to see it)
less ne supporte pas la lecture des descripteurs de fichiers sans l'option -f
 
Dans mon cas, on dirait bien que c'est la méthode /dev/fd qui est utilisé par le bash.
Pourtant, la doc de Christian CATEYDE insiste sur le fait que cette commande fait appel aux fifos.
 
allez, je vous repose ma question (il y en a qui sont partis ?   )
 
Attention .... c'est parti !
quand on utilise une substitution de processus,
que se passe-t-il ?
- utilisation de descripteurs de fichiers ?
- utilisation de fifos ?
- utilisation des deux ?
 
à tout besoin, voici le copier-coller complet (et pas long) de la doc française du man bash traitant des substitutions de processus.
 
"Substitution de Processus
La substitution de processus n'est disponible que sur les
systèmes acceptant le mécanisme des tubes nommés (FIFOs) ou la méthode /dev/fd de noms de fichiers ouverts. Elle prend la forme <(liste) ou >(liste). La liste de proces­sus est exécutée avec ses entrées et sorties connectées à une FIFO ou à un fichier  dans /dev/fd.  Le nom de ce fichier est passé en argument à la commande qui sera exécutée comme résultat de cette substitution. Si l'on utilise la forme  >(liste),  l'écriture dans le fichier fournira des entrées pour la liste. Si la forme <(liste) est utilisée, le fichier passe en argument devra être lu pour obtenir la sortie de la liste.
Sur  les  systèmes  qui  le permettent, la substitution de
processus est effectuée simultanément au remplacement des
paramètres et variables, a la substitution de commande, et à l'évaluation arithmétique.
 
Et voilà !  

 
 
Cela fait plusieurs semaines que j'ai posté la suite de mes questions sur les fifos et les descripteurs de fichiers.
 
Avez-vous une idée sur la question ?