Corriger la capitalisation des variables de script Bash et Shell

J’ai parcouru de nombreux scripts shell avec des variables en toutes lettres, et j’ai toujours pensé qu’il y avait un grave malentendu avec cela. Je crois comprendre que, par convention (et peut-être par nécessité depuis longtemps), les variables d’environnement sont en majuscules.

Mais dans les environnements de script modernes tels que Bash, j’ai toujours préféré la convention des noms minuscules pour les variables temporaires et les majuscules uniquement pour les variables exscopes (c.-à-d. L’environnement) . Par exemple:

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

Cela a toujours été mon sharepoint vue sur les 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 les variables internes du shell ( SHELL , BASH_VERSION , …) sont en majuscules. Tous les autres noms de variables doivent être en minuscules.

Rappelez-vous que les noms de variables sont sensibles à la casse. cette convention évite de déroger accidentellement aux 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 shells UNIX pour éviter de les écraser. Si c’est votre variable, mettez-la en minuscule. Si vous l’exportez, mettez-le en majuscule.

Toute convention de dénomination suivie sera toujours utile. Voici quelques conseils utiles pour nommer les variables shell:

  • Utilisez tous les caractères majuscules et les caractères de soulignement pour les variables et les constantes exscopes, en particulier lorsqu’ils sont partagés entre plusieurs scripts ou processus. Utilisez un préfixe commun chaque fois que cela est applicable pour que les variables liées se démarquent et ne se heurtent pas aux variables internes Bash qui sont toutes en majuscules.

    Exemples:

    • Variables exscopes 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” ( toutes en minuscules et en traits de soulignement ) pour toutes les variables associées à un seul script ou à un bloc.

    Exemples: first_value max_amount num_errors

    Cas mixte lorsque la variable locale a une relation avec une variable d’environnement, comme: old_IFS old_HOME

  • Utilisez un trait de soulignement principal pour les variables et les fonctions “privées”. Ceci est particulièrement pertinent si vous écrivez une bibliothèque de shell dans laquelle des fonctions dans un fichier de bibliothèque ou entre des fichiers doivent partager des variables, sans jamais se heurter à quelque chose qui pourrait être nommé de manière similaire dans le code principal.

    Exemples: _debug _debug_level _current_log_file

  • Évitez les cas de chameaux . Cela minimisera les bugs causés par les fautes de frappe. Rappelez-vous que les variables shell sont sensibles à la casse .

    Exemples: inputArray thisLooksBAD , numRecordsProcessed , veryInconsistent_style


Voir également:

  • Les spécifications de base du groupe ouvert – Problème 7 – Variables d’environnement

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

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

En réalité, le terme “variables d’environnement” semble être assez récent. Kernighan et Pike dans leur livre classique “The UNIX Programming Environment”, publié en 1984, ne parlent que des “variables shell” – il n’ya même pas d’entrée pour “environment” dans l’index!

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 vraiment de scope variable, il y a donc une bonne partie des variables utilisées comme globales (principalement des parameters et des états) et relativement peu de «locaux» (compteurs, iterators, chaînes partiellement construites et temporaires).