Devrais-je me soucier des chats inutiles?

De nombreux utilitaires de ligne de commande peuvent prendre leur entrée à partir d'un canal ou d'un argument de nom de fichier. Pour les scripts shell longs, je trouve que le démarrage de la chaîne avec la catrend plus lisible, en particulier si la première commande a besoin d'arguments sur plusieurs lignes.

Comparer

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

et

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

Cette dernière méthode est-elle moins efficace? Si tel est le cas, la différence est-elle suffisante pour que le script soit exécuté, par exemple une fois par seconde? La différence de lisibilité n'est pas énorme.

La réponse "définitive" vous est bien sûr apportée par The Useless Use of catAward .

Le but de cat est de concaténer (ou "caténer") des fichiers. S'il ne s'agit que d'un seul fichier, le concaténer sans rien est une perte de temps et vous coûte un processus.

Instancier chat juste pour que votre code se lit différemment ne nécessite qu'un processus supplémentaire et un ensemble de flux d'entrée / sortie supplémentaire qui ne sont pas nécessaires. Généralement, le blocage réel de vos scripts sera constitué par des boucles inefficaces et un traitement réel. Sur la plupart des systèmes modernes, un ajout catne va pas nuire à vos performances, mais il existe presque toujours un autre moyen d'écrire votre code.

Comme vous le constatez, la plupart des programmes peuvent accepter un argument pour le fichier d'entrée. Cependant, il existe toujours un shell intégré <qui peut être utilisé partout où un flux STDIN est attendu, ce qui vous permet d'économiser un processus en effectuant le travail dans le processus shell en cours d'exécution.

Vous pouvez même faire preuve de créativité avec O vous écrivez. Normalement, il serait placé à la fin d'une commande avant de spécifier des redirections de sortie ou des tubes comme celui-ci:

sed s/blah/blaha/ < data | pipe

Mais ça ne doit pas forcément être comme ça. Cela peut même venir en premier. Par exemple, votre exemple de code pourrait être écrit comme ceci:

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

Si la lisibilité du script vous préoccupe et que votre code est suffisamment en désordre pour que l'ajout d'une ligne catfacilite le suivi, il existe d'autres moyens de nettoyer votre code. L'une des solutions que j'utilise le plus souvent pour faciliter la compréhension des scripts consiste à diviser les canaux en ensembles logiques et à les enregistrer dans des fonctions. Le code de script devient alors très naturel et toute partie de la tôle est plus facile à déboguer.

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

Vous pouvez ensuite continuer avec fix_blahs < data | fix_frogs | reorder | format_for_sql. Une ligne de commande qui se lit comme cela est vraiment facile à suivre et les composants individuels peuvent être facilement mis au point dans leurs fonctions respectives.

Voici un résumé de certains des inconvénients de:

cat $file | cmd

plus de

< $file cmd

• Tout d’abord, une remarque: il y a (intentionnellement pour les besoins de la discussion) des guillemets doubles manquants $file. Dans le cas de cat, c'est toujours un problème sauf pour zsh; dans le cas de la redirection, ce n'est un problème que pour bashou ksh88et, pour certains autres shells, uniquement lorsqu'il est interactif (pas dans des scripts).
• L'inconvénient le plus souvent cité est le processus supplémentaire engendré. Notez que si cmdest intégré, il y a même 2 processus dans certains shells bash.
• Toujours sur le plan des performances, sauf dans les shells où catest intégré, une commande supplémentaire est également exécutée (et bien sûr chargée et initialisée (ainsi que les bibliothèques auxquelles elle est liée)).
• Toujours sur le plan de la performance, pour les gros fichiers, cela signifie que le système devra calendrier en alternance les catet les cmdprocessus et constamment remplir et vider la mémoire tampon de tuyau. Même si le cmdfait de 1GBgrands read()appels système à un moment, le contrôle devra aller et venir entre catet cmdparce qu'un tuyau ne peut pas contenir plus de quelques kilo - octets de données à la fois.
• Certains cmds (comme wc -c) peuvent faire des optimisations lorsque leur stdin est un fichier normal, ce qu’ils ne peuvent faire cat | cmdcar leur stdin n’est alors qu’un tuyau. Avec catun tuyau, cela signifie également qu'ils ne peuvent pas seek()dans le fichier. Pour des commandes telles que tacou tail, cela fait une énorme différence de performances car cela signifie catqu’elles ont besoin de stocker toute l’entrée en mémoire.
• La cat $file, et même sa version plus correcte cat -- "$file"ne fonctionnera pas correctement pour certains noms de fichiers spécifiques comme -(ou --helpou quoi que ce soit à partir de -si vous oubliez le --). Si on insiste pour utiliser cat, il devrait probablement utiliser cat < "$file" | cmdplutôt pour la fiabilité.
• S'il $filene peut pas être ouvert en lecture (l'accès est refusé, n'existe pas ...), < "$file" cmdsignalera un message d'erreur cohérent (par le shell) et ne s'exécutera pascmd , alors qu'il cat $file | cmdsera toujours exécuté cmdmais avec son stdin qui ressemble à un fichier vide. Cela signifie également que, dans des domaines tels que < file cmd > file2, file2n’est pas compressé s’il filene peut pas être ouvert.

Mettre <fileen fin de pipeline est moins lisible qu’au cat filedébut. L'anglais naturel se lit de gauche à droite.

Mettre <filele début du pipeline est également moins lisible que cat, je dirais. Un mot est plus lisible qu'un symbole, en particulier un symbole qui semble indiquer le mauvais sens.

Utiliser catpréserve le command | command | commandformat.

Une autre chose que les autres réponses à cette question ne semblent pas avoir directement abordée est que l'utilisation de cette méthode catn'est pas "inutile" dans le sens où "un processus de chat parasite est généré qui ne produit aucun travail"; c'est inutile en ce sens qu '"un processus de chat est créé qui ne fait que du travail inutile".

Dans le cas de ces deux:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

le shell démarre un processus sed qui lit un fichier ou un stdin (respectivement) puis effectue un traitement - il lit jusqu'à atteindre une nouvelle ligne, remplace le premier "foo" (le cas échéant) sur cette ligne par "bar", puis affiche cette ligne à stdout et boucles.

Dans le cas de:

cat somefile | sed 's/foo/bar/'

La coquille déclenche un processus chat et un processus sed, et connecte la sortie standard du chat à la commande stdin. Le processus cat lit un fichier de plusieurs kilos ou peut-être un mégaoctet dans le fichier, puis l'écrit sur sa sortie standard, où le sed sommand récupère à partir de là, comme dans le deuxième exemple ci-dessus. Pendant que sed traite ce morceau, chat lit un autre morceau et l’écrit sur sa sortie standard pour que sed puisse continuer.

En d'autres termes, le travail supplémentaire que nécessite l'ajout de la catcommande ne consiste pas uniquement à générer un catprocessus supplémentaire , mais également à lire et à écrire les octets du fichier deux fois au lieu d'une fois. Maintenant, pratiquement et sur les systèmes modernes, cela ne fait pas une différence énorme - cela peut obliger votre système à faire quelques microsecondes de travail inutile. Toutefois, s’il s’agit d’un script que vous prévoyez de distribuer, éventuellement aux personnes qui l’utilisent sur des machines déjà sous-alimentées, quelques microsecondes peuvent s’additionner au fil de nombreuses itérations.