Bases de l’automatisation et des scripts Bash (partie 2) –

Shutterstock / Mopic

Bash est un shell et un langage de codage idéal, vous permettant de créer des scripts d’automatisation haut de gamme. Dans cette deuxième partie de la série, nous examinerons la densité de codage, les commentaires en ligne et la correction des citations de variables à l’aide de guillemets simples ou doubles.

Bases de l’automatisation et des scripts Bash

Si vous ne l’avez pas fait et que vous venez juste de commencer dans Bash, veuillez lire notre article sur les bases de l’automatisation et des scripts Bash, partie 1. Ceci est le deuxième article de notre série en trois parties sur les bases de l’automatisation et des scripts Bash. Dans l’article d’aujourd’hui, nous examinerons, entre autres sujets, la densité de codage Bash et son lien avec les préférences des développeurs. Nous examinerons également les commentaires en ligne à ce sujet.

Une fois que nous avons commencé à créer de petits scripts, à explorer des variables et à travailler avec des chaînes de texte, nous nous rendons rapidement compte qu’il peut y avoir une différence conceptuelle entre les guillemets simples et doubles. Il y en a, et dans le deuxième sujet ci-dessous, nous allons plonger dans cela.

Densité et précision du codage Bash

Le langage de codage Bash peut être très dense et concis, mais il peut aussi être spacieux et verbeux. Cela dépend dans une large mesure des préférences des développeurs.

Par exemple, le code Bash suivant:

true || echo 'untrue'

Qui peut être lu comme Ne faites rien et faites-le avec succès (code de sortie 0), et si cela échoue (vous pouvez lire l’idiome Bash || comme OR) affiche le texte ‘faux’, peut également s’écrire:

if [ ! true ]; then
  echo 'untrue'
fi

Ce qui rend le code un peu différent, mais fait essentiellement la même chose.

Cela peut à son tour être lu comme Si vrai n’est pas (signifié par le ! idiom) true, puis affiche le texte ‘faux’.

Les deux mini-scripts donnent la même sortie vide, comme vrai n’est pas faux.

La multitude de commandes et d’outils disponibles (ou installables) depuis et sur la ligne de commande amplifie encore le décalage possible entre des scripts hautement lisibles et un code difficile à comprendre, dense et laconique.

Alors que les exemples ci-dessus sont courts et relativement faciles à comprendre, lorsque vous créez un long one-liner (un terme souvent utilisé parmi les développeurs Bash pour indiquer un morceau de code, composé de plusieurs commandes, écrites sur une seule ligne) employant plusieurs de ces commandes , au lieu de mettre la même chose dans un script plus verbeux, la différence devient plus claire. Considérer:

V="$(sleep 2 & fg; echo -n '1' | sed 's|[0-9]|a|')" && echo "${V}" | sed 's|[a-z]|2|g' || echo 'fail'

Il s’agit d’un script Bash one-liner typique qui utilise les commandes sleep, fg, echo, et sed ainsi que divers idiomes et expressions régulières Bash pour dormir 2 secondes, afficher du texte et transformer ce texte en utilisant des expressions régulières. Le script vérifie également régulièrement les conditions / résultats des commandes précédentes en utilisant les idiomes Bash || (sinon, faites ce qui suit) et && (en cas de succès, faites ce qui suit)

J’ai traduit cela, avec une fonctionnalité de correspondance approximative, en un script plus complet, avec quelques modifications. Par exemple, nous avons échangé notre fg (amene le sleep commande placée en arrière-plan au premier plan et attendez qu’elle se termine comme des processus normaux non en arrière-plan) pour wait qui attendra le PID du sommeil (démarré par eval et capturé en utilisant l’idiome Bash $!) Terminer.

#!/bin/bash

CMD="sleep 2"
eval ${CMD} &
wait $!
EXIT_CODE=${?}

V="$(echo -e "${CMD}n1" | sed 's|[0-9]|a|')"

if [ ${EXIT_CODE} -eq 0 ]; then
  echo "${V}" | sed 's|[a-z]|2|g'
  EXIT_CODE=${?}
  if [ ${EXIT_CODE} -ne 0 ]; then
    echo 'fail'
  fi
fi

Une vraie différence! Et c’est juste une développeur l’écrivant sa manière. Le code Bash écrit par d’autres a tendance à être quelque peu difficile à lire, et une telle difficulté augmente rapidement avec la densité et la concision. Pourtant, un développeur de niveau expert dans Bash comprendra rapidement même le code très dense et laconique écrit par d’autres, à quelques exceptions près, par exemple les expressions régulières.

Pour en savoir plus sur l’écriture d’expressions régulières, consultez la rubrique Comment modifier du texte à l’aide d’expressions régulières avec l’éditeur de flux sed.

D’après ces exemples, il est clair que votre kilométrage variera au fil du temps. En général, cependant, la convivialité des codeurs (en écrivant du code hautement lisible) est recommandée chaque fois que vous commencez à développer des scripts Bash.

Si vous devez créer un code dense et concis, vous pouvez fournir de nombreux commentaires en ligne. Une ligne précédée d’un # est considéré comme une ligne de commentaire / remarque, et le symbole # peut même être utilisé vers la fin d’une ligne après n’importe quelle commande exécutable, pour poster un commentaire de suffixe expliquant la commande, une instruction conditionnelle, etc. Par exemple:

# This code will sleep one second, twice
sleep 1  # First sleep
sleep 1  # Second sleep

Citations simples ou doubles citations?

Dans Bash, texte entre guillemets simples (') sont pris comme texte littéral par l’interpréteur Bash, alors que le texte entre guillemets (") est interprété (analysé) par l’interpréteur Bash. Alors que la différence dans la façon dont les choses fonctionnent peut ne pas être immédiatement claire à partir de cette définition, l’exemple suivant nous montre ce qui se passe lorsque nous échangeons ' pour " et vice versa:

echo ' $(echo "Hello world") '
echo " $(echo 'Hello world') "

Dans le premier exemple, le texte $(echo "Hello world") est considéré comme du texte littéral, et donc la sortie est simplement $(echo "Hello world") . Pour le deuxième exemple cependant, la sortie est Hello world .

L’interpréteur Bash a analysé le texte entre guillemets pour voir s’il trouverait des idiomes Bash spéciaux sur lesquels agir. Un de ces idiomes a été trouvé dans $( ... ) qui démarre essentiellement un sous-shell et exécute tout ce qui est présent entre le ( ... ) expressions idiomatiques. Pensez-y comme un shell dans un shell – un sous-shell – exécutant tout ce que vous lui passez comme une commande entièrement nouvelle. La sortie de toute commande ou commandes de ce type est ensuite renvoyée au shell de niveau supérieur et insérée à l’endroit exact où le sous-shell a été démarré.

Ainsi, notre sous-shell a exécuté echo 'Hello world' dont la sortie est Hello world. Une fois que cela a été fait, le sous-shell s’est terminé et le texte Hello world a été inséré à la place de $( ... ) invocation de sous-shell (pensez-y comme tous les $( ... ) le code est remplacé par la sortie générée par le sous-shell.

Le résultat, pour le shell supérieur, est la commande suivante: echo " Hello world ", dont la sortie est Hello world comme nous l’avons vu.

Notez que nous avons changé les guillemets doubles à l’intérieur du sous-shell en guillemets simples. Ce n’est pas nécessaire! On s’attendrait à voir une erreur d’analyse lorsqu’une commande prend la syntaxe de echo " ... " ... " ... ", en ce que les deuxièmes guillemets doubles termineraient le premier, suivis d’un autre test, et conduiraient ainsi à une erreur. Ce n’est cependant pas le cas.

Et ce n’est pas parce que Bash est flexible avec des chaînes multi-guillemets (il accepte echo 'test'"More test"'test' assez heureusement par exemple), mais parce que le sous-shell est un shell à lui tout seul, et donc des guillemets doubles peuvent être utilisés, encore une fois, à l’intérieur du sous-shell. Prouvons cela avec un exemple supplémentaire:

echo "$(echo "$(echo "more double quotes")")"

Cela fonctionnera bien et produira la sortie more double quotes. Les deux sous-interpréteurs imbriqués (exécutés dans le shell principal à partir duquel vous exécutez cela) acceptent chacun à leur tour les guillemets doubles et aucune erreur n’est générée, même si plusieurs guillemets doubles sont imbriqués dans la commande globale à une ligne. Cela montre une partie de la puissance de programmation de Bash.

En résumé

Après avoir exploré la densité de codage, nous nous rendons compte de l’intérêt d’écrire un code hautement lisible. Si nous devons néanmoins créer du code dense et laconique, nous pouvons ajouter de nombreux commentaires en ligne en utilisant # pour faciliter la lisibilité. Nous avons examiné les guillemets simples et doubles et la manière dont leurs fonctionnalités diffèrent considérablement. Nous avons également brièvement examiné les commentaires en ligne dans les scripts, ainsi que la fonctionnalité de sous-shell lorsqu’ils sont exécutés à partir d’une chaîne entre guillemets. Enfin, nous avons vu comment un sous-shell peut utiliser un autre ensemble de guillemets doubles sans pour autant affecter les guillemets doubles utilisés à un niveau supérieur de quelque manière que ce soit. Restez à l’écoute pour la partie 3!