Corriger la capitalisation des variables de script Bash et shell

Je rencontre de nombreux scripts shell avec des variables en majuscules, et j'ai toujours pensé qu'il y avait un grave malentendu à ce sujet. Je crois comprendre que, par convention (et peut-être par nécessité il y a longtemps), les variables d'environnement sont en majuscules.

Mais dans les environnements de script modernes comme Bash, j'ai toujours préféré la convention des noms en minuscules pour les variables temporaires et en majuscules uniquement pour les variables exportées (c'est-à-dire d'environnement) . Par exemple:

#!/usr/bin/env bash
year=`date +%Y`
echo "It is $year."
export JAVA_HOME="$HOME/java"

Cela a toujours été ma vision des choses. Existe-t-il des sources faisant autorité qui sont en accord ou en désaccord avec cette approche, ou est-ce purement une question de style?

Par convention, les variables d'environnement ( PAGER, EDITOR...) et des variables shell internes ( SHELL, BASH_VERSION, ...) sont capitalisés. Tous les autres noms de variables doivent être en minuscules.

N'oubliez pas que les noms de variables sont sensibles à la casse; cette convention évite de surcharger accidentellement les variables environnementales et internes.

En respectant cette convention, vous pouvez être assuré que vous n'avez pas besoin de connaître toutes les variables d'environnement utilisées par les outils ou les shells UNIX pour éviter de les écraser. Si c'est votre variable, mettez-la en minuscule. Si vous l'exportez, mettez-le en majuscule.

Toutes les conventions de dénomination suivies de manière cohérente seront toujours utiles. Voici quelques conseils utiles pour la dénomination des variables shell:

• Utilisez toutes les majuscules et les traits de soulignement pour les variables et les constantes exportées, en particulier lorsqu'elles sont partagées entre plusieurs scripts ou processus. Utilisez un préfixe commun chaque fois que cela est applicable afin que les variables liées se démarquent et ne se heurtent pas aux variables internes Bash qui sont toutes en majuscules.

  Exemples:

  • Variables exportées avec un préfixe commun: JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
  • Constantes: LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING

• Utilisez "snake case" ( tout en minuscules et traits de soulignement ) pour toutes les variables qui sont limitées à un seul script ou à un bloc.

  Exemples: input_file first_value max_amount num_errors

  Utilisez des cas mixtes lorsque la variable locale a une relation avec une variable d'environnement, comme: old_IFS old_HOME

• Utilisez un trait de soulignement pour les variables et fonctions "privées". Ceci est particulièrement pertinent si jamais vous écrivez une bibliothèque shell dans laquelle les fonctions d'un fichier de bibliothèque ou d'un fichier à l'autre doivent partager des variables, sans jamais entrer en conflit avec tout ce qui pourrait être nommé de la même manière dans le code principal.

  Exemples: _debug _debug_level _current_log_file

• Évitez le cas de chameau . Cela minimisera les bogues causés par les fautes de frappe. N'oubliez pas que les variables shell sont sensibles à la casse .

  Exemples: inputArray thisLooksBAD, numRecordsProcessed,veryInconsistent_style

Voir également:

• The Open Group Base Specifications Issue 7 - Variables d'environnement

Si les variables shell doivent être exportées vers l'environnement, il convient de considérer que la définition de variable d'environnement POSIX (numéro 7, édition 2018) spécifie:

Les noms de variables d'environnement utilisés par les utilitaires dans le volume Shell and Utilities de POSIX.1-2017 se composent uniquement de lettres majuscules, de chiffres et du trait de soulignement ( _) des caractères définis dans Portable Character Set et ne commencent pas par un chiffre.

...

L'espace de nom des noms de variable d'environnement contenant des lettres minuscules est réservé aux applications. Les applications peuvent définir toutes les variables d'environnement avec des noms provenant de cet espace de nom sans modifier le comportement des utilitaires standard.

Je fais ce que tu fais. Je doute qu'il existe une source faisant autorité, mais cela semble une norme de facto assez répandue.

En fait, le terme «variables d'environnement» semble être d'une monnaie assez récente. Kernighan et Pike dans leur livre classique "L'environnement de programmation UNIX", publié en 1984, ne parlent que de "variables shell" - il n'y a même pas d'entrée pour "environnement" dans l'index!

C'est juste une convention très répandue, je doute qu'il y ait une source "faisant autorité" pour cela.

J'ai tendance à utiliser ALL_CAPS à la fois pour l'environnement et les variables globales. bien sûr, dans Bash, il n'y a pas de vraie portée de variable, donc il y a une bonne partie des variables utilisées comme globales (principalement les paramètres et le suivi d'état), et relativement peu de `` locaux '' (compteurs, itérateurs, chaînes partiellement construites et temporaires)