Pourquoi écrire un script bash complet dans des fonctions?

Au travail, j'écris fréquemment des scripts bash. Mon superviseur a suggéré que le script entier soit divisé en fonctions, comme dans l'exemple suivant:

#!/bin/bash

# Configure variables
declare_variables() {
    noun=geese
    count=three
}

# Announce something
i_am_foo() {
    echo "I am foo"
    sleep 0.5
    echo "hear me roar!"
}

# Tell a joke
walk_into_bar() {
    echo "So these ${count} ${noun} walk into a bar..."
}

# Emulate a pendulum clock for a bit
do_baz() {
    for i in {1..6}; do
        expr $i % 2 >/dev/null && echo "tick" || echo "tock"
        sleep 1
    done
}

# Establish run order
main() {
    declare_variables
    i_am_foo
    walk_into_bar
    do_baz
}

main

Y a-t-il une raison de faire cela autre que la "lisibilité", qui, à mon avis, pourrait être tout aussi bien établie avec quelques commentaires supplémentaires et un espacement des lignes?

Cela rend-il le script plus efficace (je pense en réalité le contraire), ou facilite-t-il la modification du code au-delà du potentiel de lisibilité susmentionné? Ou est-ce vraiment juste une préférence stylistique?

Veuillez noter que, bien que le script ne le montre pas bien, "l'ordre d'exécution" des fonctions de nos scripts actuels tend à être très linéaire: cela walk_into_bardépend des choses que vous avez i_am_foofaites et do_bazagit walk_into_barcomme pouvoir échanger arbitrairement l'ordre d'exécution n'est généralement pas ce que nous ferions. Par exemple, vous ne voudriez pas soudainement mettre declare_variablesaprès walk_into_bar, cela casserait les choses.

Voici un exemple d'écriture du script ci-dessus:

#!/bin/bash

# Configure variables
noun=geese
count=three

# Announce something
echo "I am foo"
sleep 0.5
echo "hear me roar!"

# Tell a joke
echo "So these ${count} ${noun} walk into a bar..."

# Emulate a pendulum clock for a bit
for i in {1..6}; do
    expr $i % 2 >/dev/null && echo "tick" || echo "tock"
    sleep 1
done

J'ai commencé à utiliser ce même style de programmation bash après avoir lu le billet de blog "Defensive Bash Programming" de Kfir Lavi . Il donne quelques bonnes raisons, mais personnellement, je trouve celles-ci les plus importantes:

• les procédures deviennent descriptives: il est beaucoup plus facile de déterminer ce qu’une partie du code est censée faire. Au lieu d'un mur de code, vous voyez "Oh, la find_log_errorsfonction lit ce fichier journal pour rechercher les erreurs". Comparez cela avec la recherche d'un grand nombre de lignes awk / grep / sed qui utilisent dieu sait quel type de regex au milieu d'un long script - vous n'avez aucune idée de ce que ça fait là-bas sauf s'il y a des commentaires.

• vous pouvez déboguer des fonctions en incluant dans set -xet set +x. Une fois que vous savez que le reste du code fonctionne correctement, vous pouvez utiliser cette astuce pour vous concentrer sur le débogage de cette fonction spécifique uniquement. Bien sûr, vous pouvez inclure des parties de script, mais que faire si c'est une longue partie? C'est plus facile de faire quelque chose comme ça:

   set -x
   parse_process_list
   set +x

• utilisation de l'impression avec cat <<- EOF . . . EOF. Je l'ai utilisé plusieurs fois pour rendre mon code beaucoup plus professionnel. En outre, parse_args()avec la getoptsfonction est très pratique. Encore une fois, cela aide à la lisibilité, au lieu de tout placer dans le script en tant que mur de texte géant. Il est également pratique de les réutiliser.

Et bien évidemment, ceci est beaucoup plus lisible pour quelqu'un qui connaît C ou Java, ou Vala, mais qui a une expérience limitée en matière de jeu. En ce qui concerne l'efficacité, il n'y a pas beaucoup de choses que vous puissiez faire - bash n'est pas le langage le plus efficace et les gens préfèrent perl et python en termes de rapidité et d'efficacité. Cependant, vous pouvez avoir niceune fonction:

nice -10 resource_hungry_function

Comparé à un appel gentil sur chaque ligne de code, cela réduit considérablement le typage ET peut être utilisé de manière pratique lorsque vous souhaitez qu'une partie seulement de votre script s'exécute avec une priorité inférieure.

L'exécution de fonctions en arrière-plan, à mon avis, est également utile lorsque vous souhaitez que de nombreuses instructions soient exécutées en arrière-plan.

Certains des exemples où j'ai utilisé ce style:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

La lisibilité est une chose. Mais la modularisation ne se limite pas à cela. (La semi-modularisation est peut-être plus correcte pour les fonctions.)

Dans les fonctions, vous pouvez garder certaines variables locales, ce qui augmente la fiabilité et réduit les risques d’embrouillage.

Un autre avantage des fonctions est la réutilisation . Une fois qu'une fonction est codée, elle peut être appliquée plusieurs fois dans le script. Vous pouvez également le porter sur un autre script.

Votre code peut maintenant être linéaire, mais à l'avenir, vous pourrez entrer dans le domaine du multi-threading ou du multi-traitement dans le monde Bash. Une fois que vous apprenez à faire des choses dans les fonctions, vous serez bien équipé pour entrer dans le parallèle.

Un dernier point à ajouter. Comme le remarque Etsitpab Nioliv dans le commentaire ci-dessous, il est facile de rediriger les fonctions en tant qu’entité cohérente. Mais il y a un autre aspect des redirections avec des fonctions. À savoir, les redirections peuvent être définies dans la définition de la fonction. Par exemple.:

f () { echo something; } > log

Maintenant, aucune redirection explicite n'est nécessaire pour les appels de fonction.

$ f

Cela peut épargner de nombreuses répétitions, ce qui augmente encore la fiabilité et aide à garder les choses en ordre.

Voir également

• https://unix.stackexchange.com/a/483304/181255

Dans mon commentaire, j'ai mentionné trois avantages des fonctions:

1. Ils sont plus faciles à tester et à vérifier leur exactitude.

2. Les fonctions peuvent être facilement réutilisées (source) dans les futurs scripts

3. Votre patron les aime.

Et ne sous-estimez jamais l’importance du chiffre 3.

J'aimerais aborder un autre problème:

... donc pouvoir échanger arbitrairement l'ordre d'exécution n'est généralement pas ce que nous ferions. Par exemple, vous ne voudriez pas soudainement mettre declare_variablesaprès walk_into_bar, cela casserait les choses.

Pour tirer le meilleur parti du code, c’est-à-dire rendre les fonctions aussi indépendantes que possible. Si walk_into_barnécessite une variable qui n’est pas utilisée ailleurs, cette variable doit alors être définie et localisée dans walk_into_bar. Le processus de séparation du code en fonctions et de réduction de leurs interdépendances devrait rendre le code plus clair et plus simple.

Idéalement, les fonctions devraient être faciles à tester individuellement. Si, en raison des interactions, ils ne sont pas faciles à tester, c'est un signe qu'ils pourraient bénéficier de la refactorisation.

Vous divisez le code en fonctions pour la même raison que vous le feriez pour C / C ++, Python, Perl, Ruby ou tout autre code de langage de programmation. La raison la plus profonde est l'abstraction - vous encapsulez des tâches de niveau inférieur dans des primitives de niveau supérieur (fonctions), de sorte que vous n'ayez pas à vous soucier de la façon dont les choses sont accomplies. En même temps, le code devient plus lisible (et maintenable), et la logique du programme devient plus claire.

Cependant, en regardant votre code, je trouve assez étrange d’avoir une fonction pour déclarer des variables; cela me fait vraiment lever un sourcil.

Bien que je sois totalement d’accord avec la réutilisabilité , la lisibilité et le fait d’embrasser délicatement les patrons, il existe un autre avantage des fonctions de bash : la portée variable . Comme le montre le LDP :

#!/bin/bash
# ex62.sh: Global and local variables inside a function.

func ()
{
  local loc_var=23       # Declared as local variable.
  echo                   # Uses the 'local' builtin.
  echo "\"loc_var\" in function = $loc_var"
  global_var=999         # Not declared as local.
                         # Therefore, defaults to global. 
  echo "\"global_var\" in function = $global_var"
}  

func

# Now, to see if local variable "loc_var" exists outside the function.

echo
echo "\"loc_var\" outside function = $loc_var"
                                      # $loc_var outside function = 
                                      # No, $loc_var not visible globally.
echo "\"global_var\" outside function = $global_var"
                                      # $global_var outside function = 999
                                      # $global_var is visible globally.
echo                      

exit 0
#  In contrast to C, a Bash variable declared inside a function
#+ is local ONLY if declared as such.

Je ne vois pas cela très souvent dans les scripts shell du monde réel, mais cela semble être une bonne idée pour des scripts plus complexes. La réduction de la cohésion aide à éviter les bugs où vous écrasez une variable attendue dans une autre partie du code.

La réutilisation signifie souvent créer une bibliothèque commune de fonctions et l'intégrer sourcedans tous vos scripts. Cela ne les aidera pas à courir plus vite, mais cela vous aidera à les écrire plus rapidement.

Une raison complètement différente de celles déjà mentionnées dans d’autres réponses: une des raisons pour laquelle cette technique est parfois utilisée, où la seule instruction de définition non fonctionnelle au niveau supérieur est un appel à main, est de s’assurer que le script ne fait rien par inadvertance. si le script est tronqué. Le script peut être tronqué s'il passe du processus A au processus B (le shell) et que le processus A se termine pour une raison quelconque avant la fin de l'écriture de l'intégralité du script. Cela est particulièrement susceptible de se produire si le processus A récupère le script à partir d'une ressource distante. Pour des raisons de sécurité, ce n’est pas une bonne idée, c’est quelque chose qui est fait et certains scripts ont été modifiés pour anticiper le problème.

Un processus nécessite une séquence. La plupart des tâches sont séquentielles. Cela n'a aucun sens de jouer avec l'ordre.

Mais la grande chose à propos de la programmation - qui inclut les scripts - est le test. Essais, essais, essais. Quels scripts de test avez-vous actuellement pour valider l'exactitude de vos scripts?

Votre patron essaie de vous guider d’être un script kiddy à un programmeur. C’est une bonne direction à suivre. Les gens qui viendront après vous vous plairont.

MAIS. Rappelez-vous toujours vos racines orientées processus. S'il est judicieux de classer les fonctions dans l'ordre dans lequel elles sont généralement exécutées, faites-le au moins lors du premier passage.

Plus tard, vous verrez que certaines de vos fonctions traitent les entrées, les sorties, les traitements, les données de modélisation et les autres, il peut donc être judicieux de regrouper des méthodes similaires, voire de les déplacer dans des fichiers séparés. .

Plus tard, vous réaliserez peut-être que vous avez maintenant écrit des bibliothèques de petites fonctions d'assistance que vous utilisez dans beaucoup de vos scripts.

Les commentaires et l’espacement ne peuvent s’approcher de la lisibilité des fonctions, comme je vais le montrer. Sans fonctions, vous ne pouvez pas voir la forêt pour les arbres - de gros problèmes se cachent parmi de nombreuses lignes de détail. En d'autres termes, les personnes ne peuvent pas se concentrer simultanément sur les détails les plus fins et sur la grande image. Cela peut ne pas être évident dans un court script; tant qu'il reste court, il peut être assez lisible. Les logiciels ne deviennent pas plus gros, mais font certainement partie de tout le système logiciel de votre entreprise, qui est sûrement beaucoup plus grand, probablement des millions de lignes.

Considérez si je vous ai donné des instructions telles que celle-ci:

Place your hands on your desk.
Tense your arm muscles.
Extend your knee and hip joints.
Relax your arms.
Move your arms backwards.
Move your left leg backwards.
Move your right leg backwards.
(continue for 10,000 more lines)

Au moment où vous avez atteint la moitié, voire 5%, vous auriez oublié les premières étapes. Vous ne pouviez probablement pas identifier la plupart des problèmes, car vous ne pouviez pas voir la forêt pour les arbres. Comparer avec les fonctions:

stand_up();
walk_to(break_room);
pour(coffee);
walk_to(office);

C'est certainement beaucoup plus compréhensible, quel que soit le nombre de commentaires que vous pourriez insérer dans la version séquentielle ligne par ligne. Cela rend également beaucoup plus probable que vous remarquerez que vous avez oublié de préparer le café et probablement oublié sit_down () à la fin. Lorsque votre esprit pense aux détails des expressions rationnelles grep et awk, vous ne pouvez pas avoir une vue d'ensemble - "Et si on ne fait pas de café"?

Les fonctions vous permettent principalement de voir la situation dans son ensemble et de remarquer que vous avez oublié de préparer le café (ou que quelqu'un pourrait préférer le thé). À un autre moment, dans un autre état d'esprit, vous vous inquiétez de la mise en œuvre détaillée.

Il y a bien sûr d'autres avantages discutés dans d'autres réponses. Un autre avantage qui n’est pas clairement indiqué dans les autres réponses est que les fonctions fournissent une garantie importante pour la prévention et la correction des bogues. Si vous découvrez qu'une variable $ foo dans la fonction correcte walk_to () était fausse, vous savez qu'il suffit de regarder les 6 autres lignes de cette fonction pour rechercher tout ce qui aurait pu être affecté par ce problème et tout ce qui pourrait ont fait que ce soit faux. Sans fonctions (appropriées), tout et n'importe quoi dans tout le système pourrait être la cause de l'inexactitude de $ foo, et tout et n'importe quoi pourraient être affectés par $ foo. Par conséquent, vous ne pouvez pas réparer en toute sécurité $ foo sans réexaminer chaque ligne du programme. Si $ foo est local à une fonction,

Quelques truismes pertinents sur la programmation:

• Votre programme va changer, même si votre patron insiste pour dire que ce n'est pas le cas.
• Seuls le code et les entrées affectent le comportement du programme.
• Nommer est difficile.

Les commentaires commencent comme un moyen de ne pas être en mesure d'exprimer clairement vos idées dans le code * et empirent (ou sont tout simplement faux) avec le changement. Par conséquent, dans la mesure du possible, exprimez les concepts, les structures, le raisonnement, la sémantique, le flux, la gestion des erreurs et tout ce qui concerne la compréhension du code en tant que code.

Cela dit, certaines fonctions de Bash n’ont pas été trouvées dans la plupart des langues:

• L'espacement des noms est terrible dans Bash. Par exemple, si vous oubliez d'utiliser le localmot - clé, vous polluez l'espace de noms global.
• L'utilisation local foo="$(bar)"entraîne la perte du code de sortie debar .
• Il n'y a pas de paramètres nommés, vous devez donc garder à l'esprit ce qui "$@"signifie dans différents contextes.

* Je suis désolé si cela est offensant, mais après avoir utilisé des commentaires pendant quelques années et développé sans eux ** pendant plusieurs années, il est clair que ce qui est supérieur est.

** Il est toujours nécessaire d'utiliser des commentaires pour les licences, la documentation de l'API, etc.

Le temps, c'est de l'argent

Il existe d’ autres bonnes réponses qui permettent de mieux comprendre les raisons techniques pour écrire de manière modulaire un script potentiellement long, développé dans un environnement de travail, développé pour être utilisé par un groupe de personnes et pas uniquement pour votre propre usage.

Je veux me concentrer sur une attente: dans un environnement de travail "le temps, c'est de l'argent" . Ainsi, l’absence de bugs et les performances de votre code sont évaluées ainsi que la lisibilité , la testabilité, la maintenabilité, la refactorabilité, la réutilisabilité ...

Ecrire dans les "modules" un code réduira le temps de lecture nécessaire non seulement au codeur lui-même, mais même au temps utilisé par les testeurs ou par le boss. De plus, notez que le temps d'un patron est généralement mieux payé que le temps d'un codeur et que votre patron évaluera la qualité de votre travail.

De plus, écrire dans des "modules" indépendants un code (même un script bash) vous permettra de travailler "en parallèle" avec un autre composant de votre équipe, réduisant ainsi le temps de production global et utilisant au mieux les compétences du célibataire, pour réviser ou réécrire une pièce avec aucun effet secondaire sur les autres, pour recycler le code que vous venez d'écrire "tel quel"pour un autre programme / script, créer des bibliothèques (ou des bibliothèques d'extraits), réduire la taille globale et la probabilité d'erreurs associée, déboguer et tester minutieusement chaque partie ... et bien sûr, il organisera votre programme en section logique / script et améliorer sa lisibilité. Toutes les choses qui permettront d'économiser du temps et donc de l'argent. L'inconvénient est que vous devez vous en tenir aux normes et commenter vos fonctions (ce que vous devez néanmoins faire dans un environnement de travail).

Adhérer à une norme ralentira votre travail au début, mais accélérera ensuite le travail de tous les autres (et de votre vôtre). En effet, lorsque le nombre de personnes impliquées augmente, la collaboration devient un besoin inévitable. Ainsi, par exemple, même si je crois que les variables globales doivent être définies globalement et non dans une fonction, je peux comprendre un standard qui les inizialise dans une fonction declare_variables()appelée toujours dans la première ligne de celle- main()ci ...

Enfin et surtout, ne sous-estimez pas la possibilité, dans les éditeurs de code source modernes, d’afficher ou de masquer des routines séparées de manière sélective ( pliage du code ). Cela gardera le code compact et concentrera l’utilisateur sur le gain de temps.

^{Ci-dessus, vous pouvez voir comment se déroule uniquement la walk_into_bar()fonction. Même des autres lignes avaient une longueur de 1000 lignes chacune, vous pouviez toujours garder le contrôle de tout le code sur une seule page. Notez qu'il est plié même dans la section où vous allez déclarer / initialiser les variables.}

Outre les raisons données dans d'autres réponses:

9. Psychologie: un programmeur dont la productivité est mesurée en lignes de code sera incité à écrire du code inutilement détaillé. Plus la gestion se concentre sur des lignes de code, plus le programmeur est incité à développer son code avec une complexité inutile. Cela n’est pas souhaitable, car une complexité accrue peut entraîner une augmentation des coûts de maintenance et des efforts supplémentaires nécessaires pour la correction des bogues.
   • WP, lignes de code source; Inconvénients, # 9

Une autre raison souvent négligée est l'analyse syntaxique de bash:

set -eu

echo "this shouldn't run"
{
echo "this shouldn't run either"

Ce script contient évidemment une erreur de syntaxe et bash ne devrait pas l'exécuter du tout, non? Faux.

~ $ bash t1.sh
this shouldn't run
t1.sh: line 7: syntax error: unexpected end of file

Si nous encapsulions le code dans une fonction, cela ne se produirait pas:

set -eu

main() {
  echo "this shouldn't run"
  {
  echo "this shouldn't run either"
}

main

~ $ bash t1.sh
t1.sh: line 10: syntax error: unexpected end of file