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

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?

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.

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.

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.

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.

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.

À 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 ;-)

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.

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. :-)