Quel est le consensus général sur “l'utilisation inutile de chat”?

41

Lorsque je dirige plusieurs commandes unix telles que grep, sed, tr, etc., j'ai tendance à spécifier le fichier d'entrée traité par cat. Donc quelque chose comme cat file | grep ... | awk ... | sed ....

Mais récemment, après quelques commentaires laissés sur mes réponses indiquant que c'était une utilisation inutile du chat, j'ai pensé poser la question ici.

J'ai jeté un œil à la question et trouvé l'article de Wikipédia sur UUOC et The Useless Use of Cat Award . Il me semble que les arguments invoqués vont dans le sens de l'efficacité.

La question la plus proche que j'ai rencontrée ici était celle-ci: est-ce inutile d'appeler chat? - mais ce n'est pas tout à fait ce que je demande.

Je suppose que ce que le camp UUOC suggère est d'utiliser cmd1 args < file | cmd2 args | cmd3 ..ou si la commande a une option pour lire à partir d'un fichier, puis pour le passer en argument.

Mais cela me cat file | cmd1 ... | cmd2semble beaucoup plus facile à lire et à comprendre. Je n'ai pas à me souvenir des différentes manières d'envoyer des fichiers d'entrée à différentes commandes, et le processus se déroule logiquement de gauche à droite. Première entrée, puis le premier processus ... et ainsi de suite.

Est-ce que je n'arrive pas à comprendre quels arguments sont avancés à propos de l'utilisation inutile du chat? Je comprends que si j'exécute une tâche cron qui s'exécute toutes les 2 secondes et qui traite beaucoup de choses, dans ce cas, cat pourrait être un gaspillage. Mais sinon, quel est le consensus général sur l'utilisation du chat?

arunkumar
la source
16
Je suis d’accord, ici, l’appel à chat peut être inefficace, mais cela rend la commande beaucoup plus facile à comprendre et à modifier plus tard, et (surtout, IMO) sépare chaque commande différente en un seul travail, ce qui rend la tâche beaucoup plus facile à gérer. avec.
Phoshi
4
Le consensus général est qu'il n'y a pas de consensus.
Jwg
2
Ceci duplique en grande partie stackoverflow.com/questions/11710552/useless-use-of-cat (bien qu'il soit antérieur à celle-ci).
triple-
1
N'oubliez pas que cela < file cmd1 args | cmd2 args ...fonctionne aussi ... votre argument de " gauche à droite " est donc nul. Je l'utilise souvent pour plus de clarté - l'ordre que j'ai montré peut amener les gens à faire une pause, ce qui n'est pas bon. Le nombre de fils étant devenu la norme, cela devient moins un problème. IMO ...
Attie

Réponses:

21

C'est inutile dans le sens où l'utiliser comme cela n'apporte rien aux autres options, peut-être plus efficaces (par exemple, produire des résultats corrects).

Mais catest bien plus puissant que juste cat somefile. Consultez man catou lisez ce que j'ai écrit dans cette réponse . Mais si vous n’avez absolument besoin que du contenu d’un fichier, vous pourriez tirer un avantage en termes de performances si vous n’utilisez pas catpour obtenir le contenu du fichier.

En ce qui concerne la lisibilité, cela dépend de vos goûts personnels. J'aime catutiliser des fichiers dans d'autres commandes pour la même raison, surtout si les performances sont négligeables.

Cela dépend aussi de ce que vous écrivez. S'il s'agit de votre propre shell et des méthodes pratiques pour votre ordinateur de bureau, personne ne vous en souciera. Si vous tombez sur un cas dans lequel il serait préférable de rechercher le prochain outil de la chaîne, distribuez-le sous forme de logiciel fréquemment utilisé sur un système Linux minimal sur un routeur peu performant ou un périphérique similaire avec de réelles limites. capacité de traitement, c'est différent. Cela dépend toujours du contexte.

Daniel Beck
la source
3
Les coûts de performance sont-ils négligeables? Dans de nombreux cas, il s'agit de: oletange.blogspot.dk/2013/10/useless-use-of-cat-fr.html
Ole Tange
15

Dans tous les jours, l’utilisation de la ligne de commande n’est pas très différente. Vous ne remarquerez surtout pas de différence de vitesse puisque le temps passé sur le processeur évité par la non utilisation cat, votre processeur va simplement être inactif. Même si vous êtes en boucle à travers des centaines ou des milliers (voire des centaines voire de milliers) d'articles dans toute pratique , il ne va pas faire beaucoup de différence, sauf si vous êtes sur un système très chargé (charge CPU moyenne / N> 1).

Là où le caoutchouc rencontre la route, il faut former de bonnes habitudes et décourager les mauvaises. Pour traîner un cliché moisi, le diable est dans les détails. Et ce sont des détails comme celui-ci qui séparent le médiocre du grand.

C'est comme en conduisant une voiture, pourquoi faire un virage à gauche alors que vous pouvez simplement faire trois droits à la place? Bien sûr que vous pouvez, et cela fonctionne parfaitement. Mais si vous comprenez le pouvoir des virages à gauche, alors trois droits semblent tout simplement ridicules.

Il ne s'agit pas de sauvegarder un fichier, 17 ko de RAM et 0,004 seconde de temps CPU. Il s'agit de toute la philosophie d'utilisation d'UNIX. Le "pouvoir des virages à gauche" dans mon illustration ne consiste pas simplement à rediriger les entrées, mais à la philosophie UNIX. Cela vous fera exceller bien mieux que ceux qui vous entourent, et vous obtiendrez le respect de ceux qui comprennent.

bahamat
la source
2
Si vous songez à tourner à gauche sur une autoroute à six voies sans feux de circulation, vous devrez peut-être envisager de tourner à droite ou de prendre un itinéraire différent. * nix vous donne le choix entre plusieurs itinéraires. C'est une question de préférence personnelle et de lisibilité. Si vous voulez "cat file | cmd1 | cat | cmd2 | more", continuez. (Parfois, cela est utile si cmd1 pagine - cat l'éliminera.) $ CPU time << $ Brain time.
MikeP
1
@MikeP The catn'élimine aucune pagination, bien que le fait de canaliser quelque chose puisse éliminer la pagination par certaines applications.
triple-
14

J'utilise souvent cat file | myprogramdans des exemples. Parfois, on me reproche une utilisation inutile du chat ( http://www.iki.fi/era/unix/award.html ). Je ne suis pas d'accord pour les raisons suivantes:

Il est facile de comprendre ce qui se passe.

Lors de la lecture d'une commande UNIX, vous attendez une commande suivie par des arguments, suivie d'une redirection. Il est possible de placer la redirection n'importe où, mais cela se voit rarement - ainsi, les gens auront plus de difficulté à lire l'exemple. Je crois

    cat foo | program1 -o option -b option | program2

est plus facile à lire que

    program1 -o option -b option < foo | program2

Si vous déplacez la redirection au début, vous confondez des personnes qui ne sont pas habituées à cette syntaxe:

    < foo program1 -o option -b option | program2

et les exemples doivent être faciles à comprendre.

C'est facile à changer.

Si vous savez que le programme peut lire cat, vous pouvez normalement supposer qu’il peut lire le résultat de n’importe quel programme produisant vers STDOUT et que vous pouvez ainsi l’adapter à vos propres besoins et obtenir des résultats prévisibles.

Il souligne que le programme n'échoue pas si STDIN n'est pas un fichier régulier.

Il n’est pas prudent de supposer que si les program1 < footravaux fonctionnent cat foo | program1également. Cependant, il est en pratique sûr de supposer le contraire. Ce programme fonctionne si STDIN est un fichier, mais échoue si l'entrée est un canal, car il utilise la recherche:

    # works
    < foo perl -e 'seek(STDIN,1,1) || die;print <STDIN>'

    # fails
    cat foo | perl -e 'seek(STDIN,1,1) || die;print <STDIN>'

J'ai examiné la pénalité de performance sur http://oletange.blogspot.dk/2013/10/useless-use-of-cat-fr.html La conclusion est que ne l'utilisez pas cat file |si la complexité du traitement est similaire à celle d'un simple grep et la performance compte plus que la lisibilité. Pour d'autres situations cat file |c'est bien.

Ole Tange
la source
1
Enfin une réponse avec des points de repère réels. Je remarque également dans mon commentaire que "parfois" un chat peut être plus rapide. La seule fois où je peux imaginer que "l'utilisation inutile de cat" soit un désavantage, c'est si vous effectuez un traitement trivial pour d'énormes fichiers (ou si le processus peut faire un usage spécial de stdin comme la commande tail) ... unix.stackexchange. com / a / 225608/8337
rogerdpack
12

Je pense que la position adoptée par certains de ceux qui commentent quelque chose qui est un UUOC est que si on comprend vraiment la syntaxe Unix et le shell, on n’utiliserait pas cat dans ce contexte. C'est perçu comme une mauvaise grammaire: je peux écrire une phrase avec une grammaire faible tout en faisant passer mon message, mais je démontre aussi ma faible compréhension de la langue et, par extension, ma piètre éducation. Donc, dire que quelque chose est un UUOC est une autre façon de dire que quelqu'un ne comprend pas ce qu'il fait.

En ce qui concerne l'efficacité, si vous exécutez un pipeline à partir de la ligne de commande, l'exécution cat somefile |de la machine prend moins de temps que celle de savoir si son utilisation pourrait être plus efficace < somefile. Cela n'a pas d'importance.

Garyjohn
la source
6
Pendant un certain temps, je savais qu'il y avait d'autres moyens d'exprimer cat somefile | progen shell sans chat, prog < somefilemais ils semblaient toujours être dans le mauvais ordre pour moi, en particulier avec une chaîne de commandes serties ensemble. Maintenant, je vois quelque chose d'aussi élégant que < somefile progle truc, merci. Je n'ai plus d'excuses pour utiliser le chat.
Alex
4

Je n'étais pas au courant du prix jusqu'à ce jour où une recrue a essayé de me faire croire que l'UUOC était l'une de mes réponses. C'était un cat file.txt | grep foo | cut ... | cut .... Je lui ai donné une partie de mon esprit et ce n’est qu’après cela que j’ai visité le lien qu’il m’avait donné, faisant référence aux origines du prix et à sa pratique. Des recherches plus poussées m'ont amené à cette question. Malheureusement, malgré une réflexion consciente, aucune des réponses n’a inclus ma justification.

Je ne voulais pas être sur la défensive quand je l'éduquais. Après tout, dans ma jeunesse, j’aurais écrit la commande grep foo file.txt | cut ... | cut ...car, chaque fois que vous exécutez les célibataires fréquents, grepvous apprenez le placement de l’argument du fichier. Vous savez donc que le premier est le motif et que les derniers sont des noms de fichiers.

C'était un choix conscient lorsque j'ai répondu à la question avec le catpréfixe en partie pour une raison de "bon goût" (selon les mots de Linus Torvalds), mais principalement pour une raison impérieuse de fonction.

La dernière raison est plus importante, je vais donc la publier en premier. Lorsque j'offre un pipeline comme solution, je m'attends à ce qu'il soit réutilisable. Il est fort probable qu'un pipeline soit ajouté à la fin ou raccordé à un autre pipeline. Dans ce cas, avoir un argument de fichier à grep réduit les possibilités de réutilisation, et le fait probablement de manière silencieuse sans message d'erreur si l'argument de fichier existe. C'est à dire. grep foo xyz | grep bar xyz | wcvous donnera le nombre de lignes xyzcontenues barpendant que vous attendez le nombre de lignes contenant à la fois fooet bar. Devoir changer les arguments d'une commande dans un pipeline avant de l'utiliser est sujet aux erreurs. Ajoutez à cela la possibilité d'échecs silencieux et cela devient une pratique particulièrement insidieuse.

La première raison n’est pas sans importance non plus, car beaucoup de "bon goût" est simplement une logique subconsciente intuitive pour des choses comme les échecs silencieux ci-dessus que vous ne pouvez pas imaginer juste au moment où une personne ayant besoin d’éducation dit "mais ne le fait pas". ce chat inutile ".

Cependant, je vais essayer de rendre également conscient la raison "bon goût" que j'ai mentionnée. Cette raison est liée à l'esprit de conception orthogonale d'Unix. grepne fait pas cutet lsne fait pas grep. Par conséquent, à tout le moins grep foo file1 file2 file3va à l’encontre de l’esprit de conception. La façon orthogonale de le faire est cat file1 file2 file3 | grep foo. Maintenant, il grep foo file1s’agit simplement d’un cas particulier de grep foo file1 file2 file3, et si vous ne le traitez pas de la même façon, vous utilisez au moins des cycles d’horloge cérébrale en essayant d’éviter l’attribution inutile du chat.

Cela nous amène à l’argument qui grep foo file1 file2 file3concatène, et catconcatène donc comme il convient cat file1 file2 file3mais parce que catne concaténant pas, nous violons cat file1 | grep foodonc l’esprit de catl’Unix et du tout-puissant. Eh bien, si c'était le cas, Unix aurait besoin d'une commande différente pour lire la sortie d'un fichier et le cracher sur stdout (pas le paginer ni quoi que ce soit d'autre qu'un simple crachage sur stdout). Ainsi, vous auriez la situation où vous dites cat file1 file2ou que vous dites dog file1et souvenez-vous consciencieusement d’éviter cat file1d’obtenir le prix, tout en évitant dog file1 file2puisque espérons-le, la conception de dogjetterait une erreur si plusieurs fichiers sont spécifiés.

J'espère qu'à ce stade, vous sympathisez avec les concepteurs Unix pour ne pas inclure de commande distincte pour cracher un fichier sur stdout, tout en nommant catpour concaténer plutôt que de lui attribuer un autre nom. <edit>il y a un tel chien, l' <opérateur malheureux . Il est regrettable que son placement à la fin du pipeline empêche toute possibilité de composition. Il n’existe aucun moyen propre, au niveau syntaxique ou esthétique, de le placer au début. Il est également regrettable de ne pas être assez généraliste, vous devez donc commencer par le chien, mais simplement ajouter un autre nom de fichier si vous souhaitez également le traiter après le précédent. (En >revanche, ce n'est pas aussi grave. Son placement est presque parfait à la fin. Il ne s'agit généralement pas d'une partie réutilisable d'un pipeline et il est donc distingué de manière symbolique.)</edit>

La question suivante est pourquoi est-il important d’avoir des commandes qui crachent un fichier ou la concaténation de plusieurs fichiers sur stdout, sans autre traitement? Une des raisons est d'éviter d'avoir chaque commande Unix qui fonctionne sur une entrée standard pour savoir comment analyser au moins un argument de fichier de ligne de commande et l'utiliser comme entrée s'il existe. La deuxième raison est d'éviter que les utilisateurs aient à se rappeler: (a) où vont les arguments de nom de fichier; et (b) éviter le bogue du pipeline silencieux mentionné ci-dessus.

Cela nous amène à pourquoi grepa la logique supplémentaire. L'objectif est de permettre aux utilisateurs d'utiliser couramment des commandes fréquemment et de manière autonome (plutôt que sous forme de pipeline). C'est un léger compromis d'orthogonalité pour un gain de convivialité significatif. Toutes les commandes ne doivent pas nécessairement être conçues de cette façon et les commandes peu fréquemment utilisées doivent éviter complètement la logique supplémentaire des arguments de fichier (rappelez-vous que la logique supplémentaire entraîne une fragilité inutile (la possibilité d'un bogue)). L'exception consiste à autoriser les arguments de fichier comme dans le cas de grep. (Au fait, notez que la lsraison qui sous-tend une argumentation complètement différente est non seulement d’accepter mais également d’exiger des arguments de fichier)

Enfin, on aurait pu mieux faire si des commandes exceptionnelles telles que grep(mais pas nécessairement ls) généraient une erreur si l'entrée standard était disponible. Ceci est raisonnable car les commandes incluent une logique qui viole l’esprit orthogonal du tout-puissant Unix pour plus de commodité. Pour plus de commodité, c'est-à-dire pour éviter les souffrances causées par une défaillance silencieuse, ces commandes ne doivent pas hésiter à violer leur propre violation en avertissant l'utilisateur de la possibilité d'une défaillance silencieuse.

chaîne aléatoire
la source
1
Comme indiqué dans la copie croisée de cette réponse et de cette question, grep pattern f1 f2 f3la concaténation n'est pas simple . grepest au courant des fichiers et imprime les noms de fichiers (et éventuellement les numéros de ligne et autres). grep . /sys/kernel/mm/transparent_hugepage/*est un bon hack pour imprimer le nom de fichier: fichier-contenu avec beaucoup de fichiers d'une seule ligne. La conception Unix classique est que la plupart des utilitaires fonctionnent *.txtsans avoir besoin de rien cat. catest destiné à aplatir plusieurs fichiers dans un flux.
Peter Cordes
@PeterCordes Je n'ai pas tellement écrit sur grep. J'ai observé des problèmes de fond concernant la robustesse aux erreurs / copier-coller; exactitude vs performance, que vous avez commodément choisi d'ignorer au profit d'une préoccupation mineure / périphérique.
randomstring
Vous faites des remarques intéressantes et valables, en particulier sur les erreurs que vous pouvez obtenir lors du copier / coller de pipelines. Je suggérerais de remplacer votre grepexemple par un programme comme cutcelui-là qui n'a aucune raison de se soucier de plusieurs fichiers et qui pourrait toujours être alimenté depuis son stdin. Certains utilitaires, par exemple tr, n'acceptent pas du tout les arguments de fichiers et fonctionnent uniquement comme un filtre. Le choix est donc entre catet <.
Peter Cordes
1
Mon plus gros problème avec votre message est que vous actualisez la redirection des entrées. <file cmd1 | cmd2 >outCe n’est pas merveilleux, je l’avoue, mais il est tout à fait possible de s’y habituer. Vous continuez à parler de "l'esprit du tout-puissant Unix" d'une manière moqueuse, ce qui me tombe à plat parce qu'il semble que vous ne compreniez pas ou ne souhaitiez pas obtenir la même pensée que les concepteurs d'Unix. C'est bien si vous n'aimez pas le design Unix, mais ce n'est pas intrinsèquement idiot. Je ne sais pas si la conception du système d'exploitation est antérieure à la syntaxe du shell et comment tout cela a évolué, mais un supplément caten 1970 valait la peine d'être évité!
Peter Cordes
1
@PeterCordes Avec le recul, ma réponse était plutôt longue, ce qui nuit au point le plus important: la correction en premier lieu, l'optimisation en second lieu. Ce supplément cataide à réutiliser et à épisser les pipelines, sans quoi vous pouvez obtenir des échecs silencieux (recherchez "silencieusement" dans ma réponse).
randomstring
2

À la défense des utilisations inutiles du chat

(Quelques paragraphes pour aider à équilibrer le tsunami de commentaires harcelants contre cette pratique)

J'utilise bash depuis trop d'années à la fois en tant que shell et en tant que langage de script pour les petits scripts (et parfois à regret pour les moins petits). Il y a très longtemps, j'ai entendu parler de "l'utilisation inutile de chat" (UUoC). J'en suis toujours coupable au moins chaque semaine, mais franchement, je me sens rarement même un tout petit peu obligé de l'éviter. Je crois que l’utilisation de catvs < fileest plus une question de goût que de différences techniques et j’ai écrit cette réponse pour protéger les personnes novices sous Linux partageant mon goût pourcatde penser qu’il ya quelque chose qui ne va pas du tout dans leur chemin (et noter les quelques occasions où il y en a). Comme Linus Torvalds, je pense aussi que le goût est souvent plus important que les compétences. Cela ne signifie pas que mon goût est meilleur que le vôtre, mais cela signifie que si quelque chose a mauvais goût, je ne le ferai pas sans gagner quelque chose de digne.

Il est déjà évident que, à l'instar de l'auteur de la question, j'estime que l'utilisation de cat est très naturelle lorsque vous travaillez sur un REPL tel que bash où j'explore un problème en construisant progressivement des commandes complexes. Voici un exemple très typique: j'ai un fichier texte et je ne sais pas grand chose à ce sujet. Je vais taper cat filepour avoir un aperçu du contenu. Si la sortie est trop , je vais frapper ma flèche et en fonction des circonstances , je vais ajouter | headou | grep fooou | what_everétendre ma commande précédente en annexant étapes de traitement. Cette façon de passer progressivement d’une simple commande à une plus complexe en ajoutant une étape de traitement après l’autre me semble très naturelle (je fais la même chose sur ipython et j’adore le cheminpyfunctionalet des outils de programmation similaires englobent ce style). Ainsi, lorsque je travaille sur le shell bash, je suis convaincu qu'interrompre mon flux pour le retirer catest plus inutile que le laisser faire et souffrir ... eh bien, aucune conséquence du tout dans 99,9% des cas.

Bien sûr, lorsque vous écrivez des scripts, les choses peuvent changer. Mais même en écrivant des scripts, j'estime que ceux qui se moquent d'UUoC ignorent cette importante leçon: «L'optimisation prématurée est la racine de tous les maux» . Et si vous ne faites pas quelque chose d’atypique, il est très difficile pour UUoC d’être le lieu où l’optimisation sera nécessaire. Bien sûr, vous devez absolument savoir ce qui est inefficace à ce sujet (il s’agit de l’appel de processus supplémentaire BTW puisque peu de gens semblent le mentionner). Si vous avez cette connaissance, si vous travaillez sur des systèmes rares où le recours à un processus est coûteux (par exemple, certains systèmes intégrés ou CygWin dans une moindre mesure), vous saurez quoi faire si une situation particulière le requiert. Par exemple, si vous appelezcatplusieurs fois par seconde dans une boucle (Si vous vous trouvez dans cette position, demandez-vous si bash est le bon outil pour le poste). Encore une fois cependant: "faites-le d'abord fonctionner correctement puis optimisez-le si nécessaire" .

Et comment expliquez-vous le tsunami de plaintes à propos de UUoC Nick?

Bien que tout le monde n’ait pas mes goûts, je crois qu’une partie importante de la raison pour laquelle tant de gens se plaignent de UUoC n’est pas technique, mais humaine: la plupart des nouveaux venus sur Unix ne connaîtront pas l’ < file commandidiome, il est donc tentant pour une personne plus expérimentée de jouer le "Old Guru". " à eux. Il aura également l’occasion d’utiliser des mots fantaisistes ("invocation de processus") et de toucher le cher sujet de "l’optimisation". Une bonne impression est garantie, donc il est très difficile de résister. Ensuite, les nouveaux venus prendront l’avis du gourou au pied de la lettre et le rejoueront longtemps aux autres sous le nom de "La seule vérité" (et voteront contre cette réponse :-). Note amusante: il est probablement si facile de corriger bash pour éviter toute inefficacité de UUoC qu'il faut se demander pourquoi personne n'a ajouté cette fonctionnalité ou créé< filenamechat un fichier après tant d'années. Une âme sombre suggérerait que certains hackers de barbe grise aiment laisser des occasions de se moquer de nous ;-)

Ndemou
la source
+1 J'adore le dernier paragraphe expliquant pourquoi les facteurs anthropologiques qui propagent cette pratique :-)
randomstring
1

Ce qui serait vraiment bien est un shell qui supporte une syntaxe comme celle-ci:

< filename cmd | cmd2 cmd2arg1... | cmd3

Dans l’intervalle, je pense que cela cat filename | realcmd1...est acceptable, car la syntaxe est normalisée avec les commandes initiales qui exigent le nom de fichier en tant qu’argument.


la source
17
Soutiennent Bash et coquilles similaires < filename cmd | cmd2 .... Est-ce assez proche?
garyjohn
@garyjohn: Je pense que vous devriez poster cela comme réponse.
Kevin Reid
14
Ancien commentaire obligatoire sur les hackers: les obus Bourne-style soutiennent le système < file command ...depuis au moins le milieu des années 80 et probablement aussi loin que les années 70 au moment de la shrédaction de l'original . Plus généralement, les redirections d'E / S sont analysées de gauche à droite et peuvent être intercalées dans n'importe quel ordre de la ligne de commande. Donc, cmd <file arg arg...serait également valide.
Dale Hagglund
3
Oui, c'est en partie à cause de la facilité avec laquelle j'ai écrit ce que j'ai inventé le UUOC.
Randal Schwartz
2
Un personnage décalé par rapport à quatre non décalés n'est pas une si grande différence, et je préfère créer un processus supplémentaire, que même mon téléphone remarque à peine, plutôt que d'insérer un fichier dans mon invite, ce qui me donne mal à la tête chaque fois que je le vois. .
Aaron Miller
0

Pour tous ceux qui disent que chat est acceptable à utiliser car il "sent" mieux ou "est plus lisible", je dirais seulement ceci:

À vous peut-être ... mais pas à d'autres personnes qui liront ou essaieront de comprendre votre code. Si vous n'essayez jamais de montrer aux autres vos exemples ou de partager votre code, utilisez-le à votre guise.

J'ajouterai également ce commentaire, en tant qu'utilisateur Linux et administrateur / ingénieur de longue date ... (et nous sommes nombreux), cela fait saigner nos yeux. Pourquoi? Parce qu'il utilise des ressources sur des systèmes sur lesquels nous contrôlons étroitement les ressources. La commande cat et le tube lui-même utilisent de la mémoire supplémentaire et des descripteurs de fichiers totalement inutiles. Vous avez lié des ressources dont mon système a besoin gratuitement et vous n’avez rien gagné qui puisse expliquer l’utilisation de ces ressources. C'est un énorme non non.

Maintenant, je peux m'asseoir ici et débattre avec tout le monde de choses comme l'odeur du code ou la lisibilité toute la journée, mais en fin de compte, c'est une question d'écriture ou d'erreur et chaque fois que vous utilisez des ressources sur un système sans rien gagner ... il est faux.

En tant qu'utilisateur à la maison, vous pouvez apprendre de mes conseils et apprendre de meilleures façons de faire les choses ou vous pouvez choisir d'être aveuglé par "l'odeur" des chats, votre choix ... mais sachez que si vous utilisez ouvertement cette pratique, vous serez appelé sur cette pratique tout le temps et vous devrez admettre silencieusement qu'ils ont raison et vous êtes têtu parce que c'est vrai. :-)

David Dreggors
la source
Je suis également un utilisateur et développeur de logiciels de longue date pour Linux (et plus tôt * nix). Tu ne parles pas pour moi quand tu dis "ça fait saigner nos yeux" à voir cat foo.txt | .... L'autre réponse explique bien pourquoi cela peut être un bon usage. Le résumé simple du cas en faveur est le suivant: "$ temps CPU << $ temps Brain" (comme @MikeP a commenté ci-dessus).
Jim DeLaHunt
Premièrement, c'était une réponse de 2017 (moyen de faire revivre les morts lol). Deuxièmement, notez qu'en tant qu'administrateur ou développeur, nous devons toujours nous efforcer de réduire autant que possible l'utilisation des ressources. Lorsque vous écrivez des applications et des services, vous essayez de surveiller les drains de mémoire ou de processeur qui n'offrent que peu ou pas d'avantages à l'application / au service, n'est-ce pas? Eh bien, UUOC est exactement cela. Maintenant, il y a des utilisations parfaitement valables de chat qui, j'en suis sûr, impliquent une tuyauterie pour commander ... mais pas souvent. Donc, je ne parlerai peut-être pas pour vous, comme vous le dites ... mais si vous êtes un professionnel, je me demanderais pourquoi vous n’êtes pas plus facilement d’accord (compte tenu du véritable scénario UUOC).
David Dreggors le
Le problème est que les drains de mémoire ou de CPU ne sont pas le seul coût à optimiser pour un développeur. Le coût du temps humain, pour comprendre le problème et pour écrire et déboguer une implémentation, fait également partie du compromis. Certaines des réponses fournies ici reposent sur le principe selon lequel le temps humain est beaucoup plus rare et coûteux que la mémoire ou le processeur. . … Mais cela devient une discussion qui va à l’encontre des règles. Laissez les votes sur les réponses parler de la perspective approuvée par les super-utilisateurs.
Jim DeLaHunt le