Il y a certaines commandes ou astuces que vous commencez à utiliser en tant qu'administrateur système, que vous intégrez simplement dans votre arsenal et que vous ne vous arrêtez jamais vraiment pour analyser en profondeur toutes les options ou alternatives à celles-ci.
Pour moi, l'une de ces astuces est l'opérateur backtick. Je l'utilisais assez fréquemment lorsque je programmais en Perl (que je n'utilise plus aujourd'hui, mais il semble qu'il ait toujours un fan club fidèle - consultez ce sondage). Dans mes scripts Perl, j'utiliserais l'opérateur backtick pour exécuter une commande dans le système d'exploitation et renvoyer la sortie pour continuer la logique dans le script.
[ Vous pourriez également aimer : Scripts bash :comment écrire des données dans des fichiers texte ]
L'opérateur backtick est également disponible dans les scripts shell, et parce qu'il est si facile à combiner avec d'autres commandes, j'ai commencé à l'utiliser beaucoup. Cependant, il existe une manière plus "recommandée" de faire la même chose, en utilisant le $ opérateur parens (parenthèses).
Dans cet article, je vous montre les avantages et les inconvénients de chacun pour une utilisation dans des scripts shell.
La fonctionnalité de base des backticks
L'Open Group a une définition pour l'opérateur backtick, officiellement appelé substitution de commande. Cet opérateur n'est pas le guillemet simple, mais un autre caractère appelé accent grave (` ).
L'idée est simple :
❯ echo "There are `ls | wc -l` files in this directory"
There are 3 files in this directory
J'ai un groupe de commandes très simple, ls | wc -l que j'utilise pour lister et compter le nombre de fichiers dans le répertoire courant. Je peux facilement le faire de manière interactive et voir exactement quel est le résultat. Ensuite, je peux l'intégrer dans mon echo principal commande.
Dans un script shell, je pourrais certainement faire la même chose, assigner le résultat de ma commande count à une variable, puis utiliser la variable plus tard.
❯ file_count=`ls | wc -l`
❯ echo "There are $file_count files in this directory"
There are 3 files in this directory Et bien sûr, ce serait mieux si l'idée était de réutiliser la valeur ou si l'opération à effectuer n'était pas aussi simple que dans mon exemple.
L'intégration des commandes à l'aide de backticks est ce que je qualifierais de "trucs rapides et sales".
Les $ parenthèses
Vous pouvez obtenir le même résultat en remplaçant les backticks par le $ parenthèses, comme dans l'exemple ci-dessous :
❯ echo "There are $(ls | wc -l) files in this directory"
There are 3 files in this directory Voici un autre exemple, encore très simple mais un peu plus réaliste. J'ai besoin de résoudre quelque chose dans mes connexions réseau, je décide donc d'afficher mes connexions totales et en attente minute par minute.
❯ cat netinfo.sh
#!/bin/bash
while true
do
ss -an > netinfo.txt
connections_total=$(cat netinfo.txt | wc -l)
connections_waiting=$(grep WAIT netinfo.txt | wc -l)
printf "$(date +%R) - Total=%6d Waiting=%6d\n" $connections_total $connections_waiting
sleep 60
done
❯ ./netinfo.sh
22:59 - Total= 2930 Waiting= 977
23:00 - Total= 2923 Waiting= 963
23:01 - Total= 2346 Waiting= 397
23:02 - Total= 2497 Waiting= 541 Cela ne semble pas être un énorme différence, non ? J'ai juste eu à ajuster la syntaxe. Eh bien, il y a des implications impliquant les deux approches. Si vous êtes comme moi, qui utilise automatiquement les backticks sans même cligner des yeux, continuez à lire.
Abandon et recommandations
Dépréciation sonne comme un gros mot, et dans de nombreux cas, il peut être vraiment mauvais.
Lorsque je recherchais les explications de l'opérateur backtick, j'ai trouvé des discussions sur "les opérateurs backtick sont-ils obsolètes ?"
La réponse courte est :Pas dans le sens de « sur le point de devenir sans soutien et d'arrêter de travailler ». Cependant, les backticks doivent être évités et remplacés par le $ syntaxe des parenthèses.
Les principales raisons en sont (sans ordre particulier) :
1. Les opérateurs de backticks peuvent devenir désordonnés si les commandes internes utilisent également des backticks.
- Vous devrez échapper aux backticks internes, et si vous avez des guillemets simples dans les commandes ou dans les résultats, la lecture et le dépannage du script peuvent devenir difficiles.
- Si vous commencez à penser à imbriquer opérateurs backtick à l'intérieur d'autres opérateurs backtick, les choses ne fonctionneront pas comme prévu ou ne fonctionneront pas du tout. Ne vous inquiétez pas.
2. Le $ parens est plus sûr et plus prévisible.
- Ce que vous codez dans le
$L'opérateur parens est traité comme un script shell. Syntaxiquement, c'est la même chose que d'avoir ce code dans un fichier texte, vous pouvez donc vous attendre à ce que tout ce que vous coderiez dans un script shell isolé fonctionne ici.
Voici quelques exemples des différences de comportement entre les backticks et $ parenthèses :
❯ echo '\$x'
\$x
❯ echo `echo '\$x'`
$x
❯ echo $(echo '\$x')
\$x
Vous pouvez trouver des exemples supplémentaires des différences entre les backticks et $ comportement des parenthèses ici.
[ Aide-mémoire gratuit :obtenez une liste d'utilitaires et de commandes Linux pour gérer les serveurs et les réseaux. ]
Conclusion
Si vous comparez les deux approches, il semble logique de penser que vous devez toujours/uniquement utiliser le $ approche parens. Et vous pourriez penser que les opérateurs backtick ne sont utilisés que par les administrateurs système d'une époque plus ancienne.
Eh bien, c'est peut-être vrai, car parfois j'utilise des choses que j'ai apprises il y a longtemps, et dans des situations simples, ma "mémoire musculaire" les code juste pour moi. Pour les commandes ad hoc que vous connaissez et qui ne contiennent pas de caractères désagréables, vous pouvez utiliser des backticks. Mais pour tout ce qui est plus pérenne ou plus complexe/sophistiqué, merci d'utiliser le $ approche parens.