Inutile d'utiliser de chat?

C'est probablement dans de nombreux Faq - au lieu d'utiliser:

cat file | command

(qui est appelé inutile l'utilisation de chat), de manière correcte censé être:

command < file

Dans la 2e, la "bonne" façon - système d'exploitation n'ont pas à se frayer un supplément de processus.

En sachant que, j'ai continué à utiliser inutiles chat pour 2 raisons.

  1. plus esthétique - j'aime quand les données sont transférées de manière uniforme à partir de la gauche vers la droite. Et il est plus facile de remplacer cat avec quelque chose d'autre (gzcat, echo, ...), d'ajouter un 2ème fichier ou insérez un nouveau filtre (pv, mbuffer, grep ...).

  2. J'ai "senti" qu'il pourrait être plus rapide dans certains cas. Plus rapide car il y a 2 processus, 1er (cat) la lecture et la deuxième n'a quoi que ce soit. Et ils peuvent s'exécuter en parallèle, ce qui signifie parfois plus rapide d'exécution.

Est ma logique correcte (pour la 2ème raison)?

  • cat est une identité pipe. Il ne ruisseaux de son entrée à sa sortie. Si le deuxième programme de la chaîne peut prendre son entrée à partir de la même argument que vous passez à cat (ou de l'entrée standard, si vous ne transmettez pas d'argument), puis cat est absolument inutile, et seuls les résultats dans un processus supplémentaire d'être fourchue et un tuyau en cours de création.
  • quand le chat n'a pas d'arguments ou de son argument est -, c'est une identité, d'une pipe. Quand il a plus d'un non-dash argument filename il devient quelque chose de plus qu'une identité, d'une pipe, si, et commence à servir un but réel.
  • vrai, la concaténation, mais encore certains programmes se comportent de la même façon (head, tail, grep). Peut-être que je devrais avoir dit arguments, pluriel 🙂
  • L'ancien populaire lien partmaps.org est malheureusement mort. Le contenu est maintenant au porkmail.org/era/unix/award.html
  • Connexes: qu'est-Ce que le consensus général sur “Inutile l'utilisation de chat”?
  • Voir aussi: unix.stackexchange.com/q/511827/20336

InformationsquelleAutor Leonid Volnitsky | 2012-07-29
  1. 69

    Je n'étais pas au courant de la sentence jusqu'à aujourd'hui, quand certains recrue essayé à la broche de la UUOC sur moi pour l'un de mes réponses. C'était un cat file.txt | grep foo | cut ... | cut .... Je lui ai donné un morceau de mon esprit, et seulement après avoir visité le lien qu'il m'a donné en se référant aux origines de la bourse et de la pratique de le faire. Recherche m'a conduit à cette question. Malheureusement, malgré conscient considération, aucune des réponses compris mon raisonnement.

    Je n'avais pas destiné à être sur la défensive dans la réponse à lui. Après tout, dans mes jeunes années, j'aurais écrit la commande comme grep foo file.txt | cut ... | cut ... car à chaque fois que vous ne le fréquente unique greps vous savoir l'emplacement du fichier en argument et il est prêt connaissance que le premier est le modèle et les derniers sont les noms de fichier.

    C'était un choix conscient d'utiliser cat lorsque j'ai répondu à la question, en partie à cause d'une raison de "bon goût" (dans les mots de Linus Torvalds), mais surtout pour une raison convaincante de la fonction.

    La dernière raison est plus important donc je vais le mettre en premier. Lorsque j'offre un pipeline comme une solution, j'attends qu'il soit réutilisable. Il est très probable qu'un pipeline serait ajouté à la fin ou épissé dans un autre pipeline. Dans ce cas, avoir un fichier en argument à la commande grep vis jusqu'à la possibilité de réutilisation, et peut-être le faire silencieusement sans un message d'erreur si le fichier en argument existe. I. e. grep foo xyz | grep bar xyz | wc vous donnera le nombre de lignes dans xyz contenir bar pendant que vous attendez le nombre de lignes qui contiennent à la fois foo et bar. Avoir à changer les arguments d'une commande d'un pipeline avant de l'utiliser, elle est sujette aux erreurs. Ajoutez à cela la possibilité de le silence des échecs et il devient particulièrement insidieuse de la pratique.

    L'ancien raison n'est pas sans importance non plus car beaucoup de "bon goût"
    simplement est une interface intuitive subconscient justification pour des choses comme le silence de pannes ci-dessus que vous ne pouvez pas penser au moment où une personne dans le besoin de l'éducation dit: "mais n'est-ce pas que le chat inutile".

    Cependant, je vais essayer aussi de prendre conscience de la ancien "le bon goût" pourquoi je l'ai mentionné. Que la raison a à voir avec le plan orthogonal à l'esprit de Unix. grep ne pas cut et ls ne pas grep. Donc, à tout le moins grep foo file1 file2 file3 va à l'encontre de l'esprit design. Le orthogonale de la façon de le faire est cat file1 file2 file3 | grep foo. Maintenant, grep foo file1 est simplement un cas particulier de grep foo file1 file2 file3, et si vous ne le traitez pas la même que vous êtes au moins à l'aide de jusqu'au cerveau cycles d'horloge en essayant d'éviter l'inutile chat prix.

    Qui nous amène à l'argument que grep foo file1 file2 file3 est la concaténation, et cat concatène donc c'est bon pour cat file1 file2 file3 mais parce que cat n'est pas la concaténation dans cat file1 | grep foo nous sommes donc violation de l'esprit des deux les cat et le tout-puissant Unix. Eh bien, si tel est le cas, alors Unix aurait besoin d'une autre commande pour lire la sortie d'un fichier et de cracher sur la sortie standard (pas paginer ou quoi que ce soit juste une pure cracher sur la sortie standard stdout). Vous aurez donc la situation où vous dites cat file1 file2 ou vous dire dog file1 et consciencieusement n'oubliez pas d'éviter cat file1 pour éviter de contracter le prix, tout en évitant la dog file1 file2 depuis espérons que la conception de dog permettrait de lever une erreur si plusieurs fichiers sont spécifiés.

    Espérons-le, à ce stade, vous sympathiser avec les Unix concepteurs de ne pas inclure une commande distincte pour cracher un fichier sur la sortie standard, tout en nommant cat pour concaténer plutôt que de les donner un autre nom. <edit> retiré incorrect commentaires sur <, en fait, < est un moyen efficace de non-copie de la facilité à cracher un fichier sur la sortie standard que vous pouvez position au début d'un pipeline pour le Unix concepteurs ne comprennent quelque chose spécifiquement pour cette </edit>

    La prochaine question est: pourquoi est-il important d'avoir des commandes qui ne fait que cracher un fichier ou la concaténation de plusieurs fichiers sur la sortie standard, sans autre traitement? Une des raisons est d'éviter d'avoir à chaque commande Unix qui fonctionne sur l'entrée standard de savoir comment analyser au moins une ligne de commande du fichier en argument et l'utiliser comme si elle existe. La deuxième raison est d'éviter que les utilisateurs n'oubliez pas: (a) lorsque le nom de fichier arguments vont; et (b) éviter le silence pipeline bug comme mentionné ci-dessus.

    Qui nous amène à pourquoi grep a la logique supplémentaire. Le principe est de permettre à l'utilisateur d'aisance pour les commandes qui sont utilisés fréquemment et sur une autonome base (plutôt que comme un pipeline). C'est un compromis d'orthogonalité pour un gain significatif en termes de convivialité. Pas toutes les commandes doivent être conçues de cette manière et les commandes qui ne sont pas fréquemment utilisés devraient éviter complètement la logique supplémentaire de présenter des arguments (souvenez-vous de la logique supplémentaire entraîne inutile de fragilité (la possibilité d'un bug)). L'exception est de permettre à des arguments de fichier comme dans le cas de grep. (Au passage, notez que ls a une toute autre raison non seulement à accepter, mais assez bien besoin de fichier d'arguments)

    Enfin, ce qui aurait été possible de faire mieux, c'est si exceptionnelle des commandes comme grep (mais pas nécessairement ls) générer une erreur si l'entrée standard est également disponible lorsque le fichier arguments sont spécifiés.

    • Notez que lorsque grep est invoquée avec de multiples noms de fichiers, il les préfixes les lignes trouvées avec le nom du fichier qu'il a été trouvé dans (sauf si vous tournez le comportement off). Il peut également signaler les numéros de ligne dans les fichiers individuels. Si seulement utiliser cat pour nourrir grep, vous perdez les noms de fichiers et les numéros de ligne sont continues sur tous les fichiers, pas par fichier. Il y a donc des raisons pour avoir grep gérer plusieurs fichiers de même que cat ne peut pas gérer. Le seul fichier et zéro fichier cas sont simplement des cas spéciaux de la générale de multi-utilisation du fichier de grep.
    • Comme indiqué dans le répondre par kojiro, il est tout à fait possible et légal de départ à la conduite avec < file command1 .... Bien que la position classique de l'I/O opérateurs de redirection est après le nom de la commande et ses arguments, c'est seulement à la convention et non obligatoire de placement. Le < ne doivent précéder le nom de fichier. Ainsi, il y a près d'une symétrie parfaite entre >output et <input redirections: <input command1 -opt 1 | command2 -o | command3 >output.
    • les bons points. j'ai été uncharitable à < compte tenu de son positionability et de l'efficacité. et il semble bien que les commandes que de prendre plusieurs arguments de fichier de le faire pour des raisons autres que la maîtrise. par exemple wc lorsque plusieurs arguments des listes de nombres pour chaque fichier. je soupçonne un futur noyau permettra d'identité pipes dans l'espace noyau (lien ci-dessous), de sorte cat single_file pourrait éventuellement éviter les copies. je ne trouve toujours pas le cat inutile par un tronçon. si vous utilisez grep avec les numéros de ligne de votre pipeline n'est pas appendable à toute autre pipeline. si c'est de la vanille grep, cat gagne de l'OMI.
    • cs.vu.nl/~herbertb/documents/osreview2008-2.pdf - exemple de cours liées à la performance de travail
    • Je pense qu'une des raisons pourquoi les gens jettent les UUoC de pierre (y compris moi) consiste avant tout à éduquer. Parfois, les gens font du processus de gigaoctets d'énormes fichiers texte auquel cas minimiser les tuyaux (UUoC, l'effondrement des séquentielle grep dans un, une.s.o.) est cruciale et souvent, il peut être en toute sécurité pris en charge en fonction de la question que l'OP vraiment ne sait tout simplement pas que de petites modifications peuvent avoir d'énormes effets sur les performances. Je suis entièrement d'accord avec votre point de vue sur le cerveau des cycles et c'est pourquoi je me retrouve à l'aide de chat régulièrement, même lorsqu'il n'est pas nécessaire. Mais il est important de savoir qu'il n'est pas nécessaire.
    • S'il vous plaît comprendre, je suis en aucun sens de dire que cat est inutile. Ce n'est pas que cat est inutile; c'est que l'une de construire n'a pas besoin de l'utilisation de cat. Si vous aimez, notez que c'est UUoC (Inutile d'Utiliser de cat), et pas UoUC (Utilisation de l'Inutile cat). Il existe de nombreuses occasions où cat est le bon outil à utiliser; je n'ai aucun problème avec elle être utilisée que lorsque cela est le bon outil à utiliser (et, en effet, parler d'un cas dans ma réponse).
    • n'avait-je suppose que vous avez dit que. notre désaccord est en effet sur l'utilisation spécifique de cat avant un pipeline. il s'agit probablement d'un accord ou en désaccord situation en raison de l'inutilité est UNIQUEMENT pour des raisons de performances. je ne suis pas banaliser l'incidence sur les performances. si c'était java je serais d'accord. mais c'est un environnement de script, et il est injuste de de manière disproportionnée appel inutile utilise juste pour cat lorsque l'inefficacité s'applique également à dire: <file grep foo | grep bar et d'autres constructions. j'. e. "si j'avais un nickel pour chaque optimisable pipeline..."
    • il est le cas pour un unix-calcul sur les lignes de relationnel-calcul où vous déclarative spécifier votre pipeline de quelle façon, sur les lignes de SQL et le script-moteur optimise le script expression et exécute la plupart du temps dans l'espace du noyau. (analogie n'est pas beaucoup d'un tronçon si vous considérez l'impact de sort dans un pipeline). le Haskell évaluation différée des gens pourrait également avoir des idées sur la meilleure façon de l'appliquer dans un disque en moins orientée vers l'environnement. je me demande comment font-ils effondrement de leurs pipelines.
    • Je vous entends, mais je pense que ça dépend vraiment du cas d'utilisation. Lorsqu'il est utilisé sur la ligne de commande supplémentaires cat dans le tuyau à de ne pas être un gros problème, selon les données, mais lorsqu'il est utilisé comme un environnement de programmation, il peut être absolument nécessaire à la mise en œuvre de ces critiques pour les performances des choses; surtout lorsqu'il s'agit bash qui, en terme de performance, c'est comme un rectangularly en forme de roue (par rapport à ksh de toute façon. Je suis en train jusqu'à 10x plus lent ici - sans blague). Vous ne vous voulez optimiser vos fourches (et pas seulement) lorsque vous traitez avec de gros scripts ou des grandes boucles.
    • plutôt d'accord. en tant que c++/java développeur j'ai seulement écrit unix pipelines pour l'une ou pour la performance théorique des problèmes. les administrateurs système, probablement à faire le contraire. non dans le contexte de performance il y a un lego-bloc de cartographie de concepts dans ma tête pour le pipeline. oubliez cat envisager le positionnement d'un grep. un très sélective grep tôt dans le pipeline améliore les performances, comme le fait un permissive grep à la fin. mais la notion de structure dans votre cerveau, et que d'un autre lecteur a une autre structure optimale. quand le sacrifice de la carte cognitive? lorsque la loi d'amdahl l'a dit?
    • Inutile d'utilisation du "chat"? Si un chat de commande à partir d'un tuyau contribue à faire le travail, sa peine inutile dans mon livre. En va de même pour "grep trucs file.txt | wc-l", car elle aussi fait le travail (et j'en ai un de moins grep drapeau à suivre, d'économie cognitive cycles je peux l'utiliser pour d'autres choses). La Performance? Bien sûr, les performances pourraient être moins, mais avant que l'on exécute dans les situations où la différence, la devise "l'optimisation prématurée est la racine de tout mal" ont un certain mérite. Les processus SONT bon marché (et qui sont destinés à être de blocs de lego). Le cerveau des cycles de otoh, que ne le sont pas.
    • tweaks pourrait avoir d'énormes effets sur les performances" Vous ne pouvez pas écrire que sans l'appui que sur des chiffres. Mes numéros sont ici: oletange.blogspot.com/2013/10/useless-use-of-cat.html Ils disent qu'il n'ya aucun avantage pour les bas et moyen débit, mais il y a un avantage pour le haut débit.
    • les commandes doivent [...] alerte l'utilisateur si il ya une possibilité d'un silencieux bug." Je pense que c'est dur à faire: cat file | (grep foo $myfile; grep bar) je ne veux vraiment pas un avertissement de la première grep. C'est très réaliste si l' (...) est une fonction.
    • Je n'ai jamais dit que le fait d'éviter un seul UUoC auront un énorme impact sur les performances. Ce que je disais (dans le contexte) est que chaque tube (fourche) est livré avec un coût de performances et quelque chose comme cat | grep | cut | sort sera toujours beaucoup plus lent que par exemple une exécution unique de awk faire de la logique, parfois des magnitudes plus lent. Dans mon livre, il n'est pas sur la façon d'éviter un seul cat (dont les chiffres de votre spectacle ne fait pas une énorme différence, selon le débit - merci pour ça, d'ailleurs) mais l'écriture smart (en tant que bien que rapide et lisible) du code.

    InformationsquelleAutor necromancer
  2. 54

    Non!

    Tout d'abord, il n'est pas n'importe où, dans une commande de la redirection se passe. Donc si vous aimez votre redirection vers la gauche de votre commande, c'est très bien:

    < somefile command

    est le même que

    command < somefile

    Deuxième, il y a n + 1 et des processus de shell interne est exécuté qui se passe lorsque vous utilisez un tuyau. Il est certainement plus lent. Dans certains cas, n aurait été de zéro (par exemple, lorsque vous avez une redirection vers une commande interne du shell), donc en utilisant cat vous êtes l'ajout d'un nouveau processus entièrement inutilement.

    Comme une généralisation, à chaque fois que vous vous trouvez à l'aide d'un tuyau, il vaut la peine de prendre 30 secondes pour voir si vous pouvez l'éliminer. (Mais probablement pas la peine de prendre beaucoup plus de temps de 30 secondes.) Voici quelques exemples où les tuyaux et les processus sont fréquemment utilisés inutilement:

    for word in $(cat somefile); … # for word in $(<somefile); … (or better yet, while read < somefile)

grep something | awk stuff; # awk '/something/stuff' (similar for sed)

echo something | command; # command <<< something (although echo would be necessary for pure POSIX)

    N'hésitez pas à modifier afin d'ajouter d'autres exemples.

    • Ainsi, l'augmentation de la vitesse ne sera pas beaucoup.
    • en plaçant le "< somefile" avant "commande" techniquement vous donne de gauche à droite, mais c'est ambigu la lecture, car il n'est pas syntaxique de démarcation: < cat grep dog est un exemple artificiel pour montrer que vous ne pouvez pas facilement dire entre le fichier d'entrée, la commande qui reçoit l'entrée, et les arguments de la commande.
    • La règle que j'ai adopté pour décider de l'endroit où le rediriger STDIN va, c'est de faire tout ce qui minimise le apparence de l'ambiguïté/ potentiel pour la surprise. Dogmatique, en disant: elle va de l'avant apporte du nécromant problème, mais dogmatique, en disant: elle va au bout de peut faire la même chose. Considérer: stdout=$(foo bar -exec baz <qux | ENV=VAR quux). Q. est-ce que <qux s'appliquent à foo, ou à baz, qui est -execd par foo? A. Il s'applique à foo, mais peut semblent ambiguës. Mettre <qux avant foo dans ce cas est plus clair, bien que moins fréquent, et est analogue à la fuite ENV=VAR quux.
    • grep chien est plus facile à lire, là. (D'habitude je suis pro-blanc, mais ce cas particulier, est très bien une exception).
    • oui, mais c'est un périphérique d'aspect. comme mentionné dans d'autres commentaires, il est probablement deux groupes de personnes différents prioriser les deux choses différentes. C'est un peu de bienfaisance de prendre sur elle, parce que Unix, les pipelines sont rares dans la production, où la base de données et l'efficacité du réseau est la mise au point. De toute façon, bon à savoir toutes les nuances. Je ne savais pas à propos de la <"foo"' préfixe de la syntaxe; toujours pensé que la redirection est allé à la fin 🙂
    • est certainement plus lent." Vous ne pouvez pas écrire que sans l'appui que sur des chiffres. Mes numéros sont ici: oletange.blogspot.com/2013/10/useless-use-of-cat.html (et ils montrent qu'il est plus lent lorsque vous avez de hauts troughput) Où sont les vôtres?

    InformationsquelleAutor kojiro
  3. 27

    Avec le UUoC version, cat y a qu'à lire le fichier dans la mémoire, puis l'écrire dans le canal, et la commande a qu'à lire les données dans le canal, de sorte que le noyau est de copier l'ensemble du fichier trois, tandis que dans l'redirigé cas, le noyau n'a qu'à copier le fichier à la fois. Il est plus rapide de faire quelque chose une fois que de le faire trois fois.

    À l'aide de:

    cat "$@" | command

    est complètement différent et pas forcément inutile l'utilisation de cat. Il est inutile si la commande est un filtre standard qui accepte de zéro ou plus de nom de fichier arguments et les processus à leur tour. Envisager la tr de commande: c'est un pur filtre qui ignore ou rejette nom de fichier arguments. Pour nourrir plusieurs fichiers, vous devez utiliser cat comme indiqué. (Bien sûr, il y a une autre discussion que la conception de tr n'est pas très bonne; il n'y a pas vraiment de raison qu'il ne pouvait pas avoir été conçu comme un filtre standard.) Cela pourrait aussi être valable que si vous voulez que la commande à traiter toutes les entrées dans un seul fichier plutôt que comme plusieurs fichiers distincts, même si la commande acceptent plusieurs fichiers distincts: par exemple, wc est une telle commande.

    C'est le cat single-file cas inconditionnellement inutile.

    • Les commentaires ne sont pas pour de longues discussions; cette conversation a été déplacé pour chat.
    InformationsquelleAutor Jonathan Leffler
  4. 26

    Je suis en désaccord avec la plupart des instances de la trop béat UUOC Prix parce que, lors de l'enseignement de quelqu'un d'autre, cat est un endroit pratique, titulaire pour toute commande ou croustillant compliqué pipeline de commandes qui produisent de sortie adapté pour le problème ou la tâche en cours de discussion.

    Cela est particulièrement vrai sur des sites comme Dépassement de Pile, ServerFault, Unix & Linux ou tout de la SE sites.

    Si quelqu'un en fait la demande, à propos de l'optimisation, ou si vous vous sentez comme l'ajout d'informations supplémentaires à ce sujet alors, grand, de parler sur la façon d'utiliser le chat est inefficace. Mais ne pas réprimander les gens parce qu'ils ont choisi de viser la simplicité et la facilité de compréhension de leurs exemples, plutôt que de look-at-me-faire-cool-suis-je! la complexité.

    En bref, parce que le chat n'est pas toujours un chat.

    Aussi parce que la plupart des gens qui aiment passer autour de l'attribution de UUOCs le faire, car ils sont plus préoccupés par montrer comment "intelligent" ils sont ce qu'ils sont sur l'aide à l'enseignement ou les gens. En réalité, ils démontrent qu'ils sont probablement juste un autre débutant qui a trouvé un petit bâton pour battre leurs pairs.

    Mise à jour

    Voici un autre UUOC que j'ai posté dans une réponse à https://unix.stackexchange.com/a/301194/7696:

    sqlq() {
  local filter
  filter='cat'

  # very primitive, use getopts for real option handling.
  if [ "$1" == "--delete-blank-lines" ] ; then
    filter='grep -v "^$"'
    shift
  fi

  # each arg is piped into sqlplus as a separate command
  printf "%s\n" "$@" | sqlplus -S sss/eee@sid | $filter
}

    UUOC pédants dirais que c'est un UUOC parce qu'il est facilement possible de faire $filter par défaut à la chaîne vide et ont la if déclaration ne filter='| grep -v "^$"' mais l'OMI, par ne pas intégrer le caractère pipe dans $filter, cette "inutile" cat sert extrêmement utile à des fins d'auto-documenter le fait que $filter sur le printf ligne n'est pas juste un autre argument pour sqlplus, c'est une option sélectionnable par l'utilisateur filtre de sortie.

    Si il y a besoin d'avoir plusieurs option de sortie des filtres, l'option de traitement pourrait simplement ajouter | whatever à $filter aussi souvent que nécessaire - un extra cat dans le pipeline n'est pas mal quoi que ce soit ou causer une perte notable de performance.

    • En aparté -- == à l'intérieur de [ ] n'est pas spécifiée par POSIX, et non pas toutes les implémentations de l'accepter. La standardisation de l'opérateur est juste =.
    InformationsquelleAutor cas
  5. 19

    Dans défense de chat:

    Oui, 

       < input process > output

    ou 

       process < input > output

    est plus efficace, mais beaucoup d'invocations n'ont pas de problèmes de performance, de sorte que vous n'avez pas de soins.

    ergonomique raisons:

    Nous sommes habitués à lire de gauche à droite, donc une commande comme 

        cat infile | process1 | process2 > outfile

    est facile à comprendre. 

        process1 < infile | process2 > outfile

    a pour sauter par-dessus de fabrication1, puis de les lire de gauche à droite. Ce peut être guérie par:

        < infile process1 | process2 > outfile

    semble d'une certaine manière, comme s'il y avait une flèche pointant vers la gauche, où rien ne l'est. Plus de confusion et de la recherche comme de fantaisie devis est: 

        process1 > outfile < infile

    et de générer des scripts est souvent un processus itératif, 

        cat file 
    cat file | process1
    cat file | process1 | process2 
    cat file | process1 | process2 > outfile

    où vous pouvez voir votre progression par étapes, tout en

        < file

    pas de même des œuvres. Des moyens simples sont moins enclins à faire des erreurs et ergonomique commande enchaînement est simple avec un chat.

    Un autre sujet, que la plupart des gens ont été exposés à > et < que les opérateurs de comparaison, longtemps avant l'utilisation d'un ordinateur et lors de l'utilisation d'un ordinateur en tant que programmeurs, sont plus souvent exposés à ces en tant que tel.

    Et la comparaison des deux opérandes avec des < et >, est contre commutative, ce qui signifie 

    (a > b) == (b < a)

    Je me souviens de la première fois à l'aide de < pour la redirection d'entrée, je craignais 

    a.sh < file

    pourrait dire la même chose que 

    file > a.sh

    et en quelque sorte remplacer mon un.sh script. Peut-être est-ce un problème pour beaucoup de débutants.

    rares différences

    wc -c journal.txt
15666 journal.txt
cat journal.txt | wc -c 
15666

    Ce dernier peut être utilisé dans les calculs directement. 

    factor $(cat journal.txt | wc -c)

    Bien sûr, le < peut être utilisé ici aussi, au lieu d'un fichier de paramètre:

    < journal.txt wc -c 
15666
wc -c < journal.txt
15666

    mais qui s'en soucie - 15k?

    Si j'irait parfois à des problèmes qui, sûrement, je voudrais changer mon habitude de facturation chat.

    Lors de l'utilisation de très grande ou de de nombreux, de nombreux fichiers, en évitant le chat est très bien. Pour la plupart des questions de l'utilisation du chat est orthogonale, hors sujet, pas un problème.

    Le démarrage de ces inutiles inutiles utilisation de chat de discussion sur chaque deuxième shell sujet est seulement gênant et ennuyeux. Obtenir une vie et d'attendre pour votre minute de gloire, lorsqu'ils traitent de questions de performances.

    • +11111 .. Comme l'auteur de la actuellement accepté de répondre, je recommande fortement ce délicieux complément. Les exemples élucider mon souvent abstraite et verbeux arguments, et le rire que vous obtenez de l'auteur au début de l'appréhension de file > a.sh vaut à lui seul la lecture de ce présent 🙂 Merci pour le partage!
    InformationsquelleAutor user unknown
  6. 17

    Un problème supplémentaire est que le tuyau peut silencieusement masque un shell interne est exécuté. Pour cet exemple, je vais remplacer cat avec echo, mais il existe le même problème.

    echo "foo" | while read line; do
    x=$line
done

echo "$x"

    Vous pourriez vous attendre x pour contenir foo, mais il ne le fait pas. Le x vous définissez était dans un shell interne est exécuté donné naissance à exécuter le while boucle. x dans le shell qui a commencé le pipeline a une autre valeur, ou n'est pas définie.

    Dans bash4, vous pouvez configurer les options d'environnement, de sorte que la dernière commande d'un pipeline s'exécute dans le même shell comme celui qui commence le pipeline, mais vous pouvez essayer ce

    echo "foo" | while read line; do
    x=$line
done | awk '...'

    et x est une fois de plus, local à l' while's shell interne est exécuté.

    • Dans strictement POSIX coquilles cela peut être un problème délicat, car vous n'avez pas ici de chaînes ou de processus de substitution pour éviter la pipe. BashFAQ 24 a quelques solutions utiles, même dans ce cas.
    • Dans certains coques illustrée, tuyau de ne pas créer un shell interne est exécuté. Les exemples incluent Korn et Z. Ils prennent également en charge le processus de substitution et d'ici chaînes. Bien sûr, ils ne sont pas strictement POSIX. Bash 4 a shopt -s lastpipe pour éviter de créer de la shell interne est exécuté.
    InformationsquelleAutor chepner
  7. 13

    Comme quelqu'un qui régulièrement points et d'un certain nombre d'autres programmation shell antipatterns, je me sens obligé de, tardivement, de peser dans.

    Script Shell est très bien un copier/coller de la langue. Pour la plupart des gens qui écrivent les scripts shell, ils ne sont pas là pour apprendre la langue, c'est juste un obstacle à surmonter pour continuer à faire des choses dans la ou les langue(s) ils sont en fait assez bien.

    Dans ce contexte, je le vois comme un élément perturbateur et potentiellement destructrice pour propager les différents scripts shell anti-modèles. Le code que quelqu'un le trouve sur Stack Overflow, idéalement, devrait être possible de copier/coller dans leur environnement avec un minimum de modifications, et de la compréhension incomplète.

    Parmi les nombreux scripts shell ressources sur le net, Stack Overflow est inhabituel dans la mesure où les utilisateurs peuvent contribuer à façonner la qualité du site en modifiant les questions et les réponses sur le site. Cependant, code de modifications peuvent être problématiques car il est facile de faire des changements qui n'étaient pas prévus par le code de l'auteur. Par conséquent, nous avons tendance à nous laisser des commentaires afin de suggérer des modifications pour le code.

    La UUCA et liées antipattern commentaires ne sont pas seulement pour les auteurs du code commentaire; ils sont autant un caveat emptor pour aider lecteurs du site de devenir conscient des problèmes dans le code qu'ils trouvent ici.

    On ne peut pas espérer parvenir à une situation où aucune des réponses sur un Débordement de Pile recommander inutile cats (ou non cotées variables, ou chmod 777, ou à une grande variété d'autres antipattern fléaux), mais on peut au moins aider à éduquer l'utilisateur qui est sur le point de copier/coller ce code dans les recoins les plus profonds boucle serrée de leur script qui exécute des millions de fois.

    Autant que des raisons techniques, aller, la sagesse traditionnelle, c'est que nous devrions essayer de minimiser le nombre de processus externes; c'est toujours une bonne orientation générale lors de l'écriture de scripts shell.

    • Aussi que pour les gros fichiers, de la tuyauterie à travers cat est beaucoup de changements de contexte et de bande passante mémoire (et de la pollution de cache L3 de copies supplémentaires de données dans cat's en lecture de la mémoire tampon, et le tuyau de tampons). Surtout sur un grand multi-core de la machine (comme beaucoup d'hébergement configurations de cache / mémoire, la bande passante est une ressource partagée.
    • Merci de poster vos mesures. Nous pouvons donc est de savoir si c'est vraiment important dans la pratique. Mon expérience est que normalement, il n'a pas d'importance: oletange.blogspot.com/2013/10/useless-use-of-cat.html
    • Votre propre blog montre 50% de ralentissement de haut débit, et vous n'êtes même pas regarder l'impact sur le total du débit (si vous aviez des trucs en gardant les autres cœurs occupé). Si je me déplace pour elle, je pourrais exécuter vos tests tout en x264 ou x265 sont de l'encodage d'une vidéo à l'aide de tous les cœurs, et de voir combien il ralentit l'encodage de la vidéo. bzip2 et gzip de compression sont à la fois très lent par rapport au montant des frais généraux cat ajoute à cela seul (avec la machine inactif). Il est difficile de lire vos tables (wrap ligne au moyen d'un numéro?). sys temps augmente beaucoup, mais encore faible vs. utilisateur ou le real?
    InformationsquelleAutor tripleee
  8. 7

    J'utilise souvent cat file | myprogram dans les exemples. Parfois, je m'accuse de l'Inutile l'utilisation de chat (http://porkmail.org/era/unix/award.html). Je suis en désaccord pour les raisons suivantes:

    • Il est facile de comprendre ce qui se passe.

      Lors de la lecture d'une commande UNIX vous vous attendez à une commande suivie par des arguments suivie par la redirection. Il est possible de mettre la redirection n'importe où, mais il est rarement vus, donc les gens vont avoir un moment plus difficile la lecture de 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 vers le début vous êtes à confusion, des gens qui ne sont pas utilisés à cette syntaxe:

      < foo program1 -o option -b option | program2

      et les exemples doivent être faciles à comprendre.

    • Il est facile de changer.

      Si vous connaissez le programme peut lire à partir de cat, vous pouvez normalement supposer qu'il peut lire le rendement de n'importe quel programme qui affiche sur la sortie standard, et donc vous pouvez l'adapter à vos propres besoins et d'obtenir des résultats prévisibles.

    • Il souligne que le programme n'a pas manqué, si STDIN n'est pas un fichier.

      Il n'est pas sûr de supposer que si program1 < foo fonctionne alors cat foo | program1 fonctionnera également. Cependant, il est sûr de supposer le contraire. Ce programme fonctionne si STDIN est un fichier, mais échoue si l'entrée est une pipe, parce qu'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>'

    Coût de

    Il y a un coût supplémentaire cat. Pour donner une idée de la façon dont beaucoup j'ai couru quelques tests pour simuler des données de référence (cat), à faible débit (bzip2), moyen débit (gzip), et à haut débit (grep).

    cat $ISO | cat
< $ISO cat
cat $ISO | bzip2
< $ISO | bzip2
cat $ISO | gzip
< $ISO gzip
cat $ISO | grep no_such_string
< $ISO grep no_such_string

    Les tests ont été exécutés sur un bas de gamme (0.6 GHz) et un ordinateur portable ordinaire (2.2 GHz). Ils ont été exécutés 10 fois sur chaque système et le meilleur moment a été choisi pour imiter la situation optimale pour chaque test. L' $ISO ubuntu-11.04-desktop-i386.iso.
    (Plus joli tableaux ici: http://oletange.blogspot.com/2013/10/useless-use-of-cat.html)

    CPU                       0.6 GHz ARM
Command                   cat $ISO|                        <$ISO                            Diff                             Diff (pct)
Throughput \ Time (ms)    User       Sys        Real       User       Sys        Real       User       Sys        Real       User       Sys        Real
Baseline (cat)                     55      14453      33090         23       6937      33126         32       7516        -36        239        208         99
Low (bzip2)                   1945148      16094    1973754    1941727       5664    1959982       3420      10430      13772        100        284        100
Medium (gzip)                  413914      13383     431812     407016       5477     416760       6898       7906      15052        101        244        103
High (grep no_such_string)      80656      15133      99049      79180       4336      86885       1476      10797      12164        101        349        114
CPU                       Core i7 2.2 GHz
Command                   cat $ISO|           <$ISO             Diff          Diff (pct)
Throughput \ Time (ms)    User     Sys Real   User   Sys Real   User Sys Real User       Sys Real
Baseline (cat)                    0 356    215      1  84     88    0 272  127          0 423  244
Low (bzip2)                  136184 896 136765 136728 160 137131 -545 736 -366         99 560   99
Medium (gzip)                 26564 788  26791  26332 108  26492  232 680  298        100 729  101
High (grep no_such_string)      264 392    483    216  84    304   48 308  179        122 466  158

    Les résultats montrent que pour les bas et moyen débit, le coût est de l'ordre de 1%. C'est bien dans l'incertitude des mesures, de sorte que, dans la pratique, il n'y a pas de différence.

    Pour un débit élevé, la différence est plus grande et il y a une nette différence entre les deux.

    Qui mène à la conclusion: Vous devez utiliser < au lieu de cat | si:

    • la complexité du traitement est similaire à un simple grep
    • des questions de rendement de plus de lisibilité.

    Sinon il n'a pas d'importance si vous utilisez < ou cat |.

    Et donc vous ne devriez donner un UUoC-prix si et seulement si:

    • vous pouvez mesurer une différence significative dans les performances (publier vos mesures lorsque vous donnez le prix)
    • des questions de rendement de plus de lisibilité.
    InformationsquelleAutor Ole Tange
  9. -3

    Je pense que (la manière traditionnelle) à l'aide de tuyau est un peu plus rapide; sur mon boitier j'ai utilisé strace commande pour voir ce qu'il se passe:

    Sans tuyau:

    toc@UnixServer:~$ strace wc -l < wrong_output.c
execve("/usr/bin/wc", ["wc", "-l"], [/* 18 vars */]) = 0
brk(0)                                  = 0x8b50000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ad000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29107, ...}) = 0
mmap2(NULL, 29107, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77a5000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\222\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1552584, ...}) = 0
mmap2(NULL, 1563160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7627000
mmap2(0xb779f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178) = 0xb779f000
mmap2(0xb77a2000, 10776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77a2000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7626000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb76268d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb779f000, 8192, PROT_READ)   = 0
mprotect(0x804f000, 4096, PROT_READ)    = 0
mprotect(0xb77ce000, 4096, PROT_READ)   = 0
munmap(0xb77a5000, 29107)               = 0
brk(0)                                  = 0x8b50000
brk(0x8b71000)                          = 0x8b71000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5540198, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7426000
mmap2(NULL, 1507328, PROT_READ, MAP_PRIVATE, 3, 0x2a8) = 0xb72b6000
close(3)                                = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ac000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb77ac000, 4096)                = 0
open("/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr_FR.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr_FR/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=316721, ...}) = 0
mmap2(NULL, 316721, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7268000
close(3)                                = 0
open("/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=26064, ...}) = 0
mmap2(NULL, 26064, PROT_READ, MAP_SHARED, 3, 0) = 0xb7261000
close(3)                                = 0
read(0, "#include<stdio.h>\n\nint main(int "..., 16384) = 180
read(0, "", 16384)                      = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7260000
write(1, "13\n", 313
)                     = 3
close(0)                                = 0
close(1)                                = 0
munmap(0xb7260000, 4096)                = 0
close(2)                                = 0
exit_group(0)                           = ?

    Et avec tuyau:

    toc@UnixServer:~$ strace cat wrong_output.c | wc -l
execve("/bin/cat", ["cat", "wrong_output.c"], [/* 18 vars */]) = 0
brk(0)                                  = 0xa017000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb774b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29107, ...}) = 0
mmap2(NULL, 29107, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7743000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\222\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1552584, ...}) = 0
mmap2(NULL, 1563160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75c5000
mmap2(0xb773d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178) = 0xb773d000
mmap2(0xb7740000, 10776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7740000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75c4000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75c48d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb773d000, 8192, PROT_READ)   = 0
mprotect(0x8051000, 4096, PROT_READ)    = 0
mprotect(0xb776c000, 4096, PROT_READ)   = 0
munmap(0xb7743000, 29107)               = 0
brk(0)                                  = 0xa017000
brk(0xa038000)                          = 0xa038000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5540198, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb73c4000
mmap2(NULL, 1507328, PROT_READ, MAP_PRIVATE, 3, 0x2a8) = 0xb7254000
close(3)                                = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
open("wrong_output.c", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=180, ...}) = 0
read(3, "#include<stdio.h>\n\nint main(int "..., 32768) = 180
write(1, "#include<stdio.h>\n\nint main(int "..., 180) = 180
read(3, "", 32768)                      = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
13

    Vous pouvez faire quelques essais avec strace et time de commande avec de plus en plus de commandes pour de bon de l'analyse comparative.

    • Je ne comprends pas ce que tu veux dire par (de manière traditionnelle) à l'aide de pipe, ou pourquoi vous pensez que ce strace montre qu'il est plus rapide – le strace n'est pas de retracer le wc -l d'exécution dans le second cas. Il ne les traces de la première commande du pipeline ici.
    • je veux dire par la façon traditionnelle = la méthode la plus utilisée (je pense que nous utilisons pipe plus d'indirection), je ne peux pas confirmer que c'est plus rapide ou pas, dans ma trace, j'ai vu plus d'appels système pour l'indirection. Vous pouvez utiliser un programme c et une boucle à voir avec les consommer le plus de temps. Si vous êtes intéressé, nous pouvons le mettre ici 🙂
    • Comme c'est à l'heure actuelle, le strace de sortie n'a pas fait de montrer les appels associés à la mkfifo() surcharge de ou la redirection de frais généraux. En tant que tel, il est totalement dénué de pertinence pour la détermination de la performance réelle de delta; tout ce que vous êtes en comparant est la différence entre strace wc -l et strace cat -- le pipeline-vs-redirection différence n'a aucune incidence sur le contenu collé dans cette réponse.
    • Une des pommes avec des pommes comparaison permettrait de mettre strace -f sh -c 'wc -l < wrong_output.c' aux côtés de strace -f sh -c 'cat wrong_output.c | wc -l'.
    • Un simple test le long de ces lignes est très concluants -- plus de temps horloge murale sans un pipeline, mais moins user+sys temps, donc plus efficaces d'un point de vue du système. (J'ai pris le strace parce que ce n'est pas ce que nous voulons mesurer.) Mon test a wc -l sur 13 000 ligne fichier de 1000 fois dans un Bash for n in {1..1000} boucle.
    • Voici les résultats de ideone.com qui actuellement sont clairement en faveur des sans cat: ideone.com/2w1W42#stderr
    • crée un nom tuyau. Un canal anonyme est mis en place avec pipe(2) et ensuite bifurquer, et d'avoir la mère et de l'enfant à proximité différentes extrémités de la canalisation. Mais oui, cette réponse est un non-sens total, et n'a même pas essayer de compter les appels système ou de l'utilisation strace -O à mesure de la surcharge, ou -r à l'horodatage de chaque appel par rapport à la dernière...

    InformationsquelleAutor TOC