S-GAIA a écrit :
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.
> redirige la sortie standard (c'est a dire ce qui s'affiche sur la console en temps normal) la ou tu lui dis (dans un fichier par exemple donc).
< redirige l'entrée standard (c'est a dire ton clavier en temps normal) de la commande (depuis un fichier par exemple)
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
Voila, en gros y a 3 flux important :
1) entrée standard (< )
2) sortie standard (> )
2) sortie erreur (2> )
* 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)
C'est pour signifier que la commande ls doit etre executée avant le cat (forcement). D'ou l'utilisation de pipe pour recuperer la sortie de la premiere commande (le 'ls' entre parenthèses), et l'utiliser comme entrée de la seconde (le 'cat'.
En gros faut voir les '(' et '' comme pour les operations mathematiques... pour simplifier..
* 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!)
-r : recursif
-s : ne pas afficher les messages d'erreurs comme les droits d'acces ou les liens foireux
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
Citation :
Extrait du man de less :
It is also possible to set up an input preprocessor to
pipe the file data directly to less, rather than putting
the data into a replacement file. This avoids the need to
decompress the entire file before starting to view it. An
input preprocessor that works this way is called an input
pipe. An input pipe, instead of writing the name of a
replacement file on its standard output, writes the entire
contents of the replacement file on its standard output.
If the input pipe does not write any characters on its
standard output, then there is no replacement file and
less uses the original file, as normal. To use an input
pipe, make the first character in the LESSOPEN environment
variable a vertical bar (|) to signify that the input pre
processor is an input pipe.
|
Citation :
Extrait du man cat :
cat affiche sur la sortie standard le contenu de chacun
des fichiers indiqués (ou le contenu de l'entrée standard
si aucun nom de fichier n'est fourni, ou si le nom `-' est
indiqué).
|
Tu vois que ca y est...
Mais en gros t'as tout compris... si le programme a été concu pour lire un flux en entrée/balancer u flux en sortie, alors tu peux t'en servir, sinon, non...
Bon, ce sera tout pour ce soir.
Merci à tous pour le temps que vous passez à me lire.
|