GNU/Linux >> Tutoriels Linux >  >> Linux

Choc d'obus ? Non, ShellCheck ! Trouvez des bogues dans vos scripts.

Écrire de bons scripts est difficile. Il y a la compétence PEBKAC évidente, bien sûr, mais aussi la magie et l'histoire anciennes, avec des conventions héritées allant à Plan 9 et FLOW-MATIC, que la plupart des gens ne comprennent pas vraiment ou ne se soucient pas vraiment lors de l'écriture de leur logiciel. Ensuite, l'absence d'un crime et d'un châtiment dostoïevskien dans le développement de logiciels signifie également que les codes peuvent être paresseux et écrire comme bon leur semble.

Il y a un tas de lunes, je suis tombé sur un petit programme sympa conçu pour rendre votre script shell moins nul. Il s'appelle ShellCheck, il est disponible en tant que console en ligne, et vous pouvez également l'installer dans à peu près n'importe quelle distribution, puis l'intégrer dans vos flux de travail ou autre. Intrigué, je suis parti en exploration.

Feu dans le trou

J'ai commencé avec mon propre script shell - simWANsim, un programme conçu pour simuler la latence du réseau WAN d'une manière simple et pratique (pas besoin d'interfaces multiples, de médias en direct ou autres). Il s'agit essentiellement d'un script BASH, et je voulais voir à quel point il est efficace et élégant. BTW, le script n'a pas besoin d'être exécutable pour être évalué.

shellcheck "nom du script"

J'ai été surpris par le nombre d'erreurs et d'avertissements, mais ensuite, lorsque j'ai commencé à lire, beaucoup d'entre eux étaient en fait plusieurs instances du même type de mauvaise pratique de codage, répétées plusieurs fois dans le script. De plus, j'ai réalisé que les erreurs avaient un sens, qu'elles étaient écrites de manière claire et que ce n'était pas juste du blabla techno aléatoire. Suggestions pratiques et utiles - avec des exemples - sur la façon de corriger vos scripts.

L'une des erreurs courantes était l'utilisation de backticks plutôt que la notation $(). J'ai également eu plusieurs autres lignes dans la même veine, l'utilisation de let expr, l'absence de guillemets doubles pour empêcher le globbing et le fractionnement des mots, et quelques autres problèmes mineurs comme celui-là.

Dans la ligne 152 de simWANsim.sh :
EGREP=`which egrep`
^-----------^ SC2006 :utilisez la notation $(...) au lieu de l'ancien backticked `. ..`.
^---^ SC2230 :qui n'est pas standard. Utilisez la 'commande -v' intégrée à la place.

Voulez-vous dire :
EGREP=$(quel egrep)

Dans simWANsim.sh ligne 304 :
let PRNT=$PRNT+1
^-------------^ SC2219 :Au lieu de 'let expr', préférez (( expr )) .

J'ai été impressionné par l'étude de cas [sic]. Salut salut. J'avais utilisé des options que je n'avais pas vraiment gérées, et je n'avais pas non plus de cas générique pour les drapeaux non spécifiés. Cela ressemble à une petite suggestion intelligente. Le plus rusé.

Dans simWANsim.sh ligne 178 :
case $flag in
^-- SC2213 :getopts a spécifié -a, mais il n'est pas géré par ce 'case'.
^-- SC2213 :getopts a spécifié -s, mais ce n'est pas géré par ce 'cas'.
^-- SC2220 :Les indicateurs non valides ne sont pas gérés. Ajoutez un cas *).

Aucun d'entre eux n'est cardinal, mais alors pourquoi pas. Après tout, si vous pouvez rendre votre code aussi propre et élégant que possible, vous éliminez la possibilité d'erreurs de casse et de comportement étrange. Je n'aime pas écrire du code, mais si vous le faites, autant le faire correctement.

J'ai également testé un script très générique pour voir ce qui se passe lorsqu'il n'y a pas d'erreurs. L'outil de ligne de commande se ferme simplement, sans aucune sortie. Si vous utilisez l'outil en ligne, vous recevrez un message imprimé indiquant :

$ shellcheck monscript
Aucun problème détecté !

Enfin, vous pouvez embellir votre sortie, modifier la verbosité de la sortie, le style et les couleurs du format, forcer ShellCheck à travailler avec un dialecte spécifique du shell (y compris sh, bash, dash et ksh), afficher des liens wiki, ce qui peut être utile pour ceux qui recherchent pour obtenir des informations et des ressources supplémentaires sur leurs pratiques et erreurs de codage, ainsi que quelques autres options. Dans l'ensemble, c'est simple, efficace et élégant.

Conclusion

ShellCheck est un utilitaire vraiment cool. Normalement, je n'aime pas beaucoup les choses de ce genre, mais je peux apprécier la beauté quand il y en a. L'outil lui-même a été écrit en Haskell, ce qui nous place tous dans un plan métaphysique complètement différent, mais nous n'en voudrons pas en vouloir à l'auteur.

S'il vous arrive d'utiliser des scripts shell dans votre environnement, vous voudrez peut-être envisager d'essayer ShellCheck. Je pense que vous serez surpris, car il devrait y avoir des tonnes de petites erreurs héritées dans votre code, car les gens reviennent rarement en arrière et corrigent de vieilles choses, et vous vous retrouvez avec des restes qui n'ont plus de sens ou ne servent à rien. À l'ère des ballonnements inutiles, être frugal et élégant compte. C'est une façon intelligente de commencer votre régime de coquilles. Et ainsi se termine un autre article.


Linux
  1. Autoriser Setuid sur les scripts Shell ?

  2. Expiration du délai dans un script shell ?

  3. Tableaux associatifs dans les scripts shell ?

  4. Verrouiller correctement les scripts Shell ?

  5. Enregistrer le résultat de la recherche en tant que variable dans un script shell ?

Comment créer des scripts shell

ShellCheck - Un utilitaire gratuit pour trouver des bogues dans vos scripts Shell

Masquer le mot de passe dans les scripts shell ?

Bash Beginner Series #1 :Créez et exécutez votre premier script shell Bash

Tableaux dans les scripts shell

Script Shell/Bash pour trouver des nombres premiers sous Linux