Corregir las mayúsculas variables del script Bash y shell

Me encuentro con muchos scripts de shell con variables en mayúsculas, y siempre he pensado que hay un malentendido grave con eso. Tengo entendido que, por convención (y tal vez por necesidad hace mucho tiempo), las variables de entorno están en mayúsculas.

Pero en los entornos de scripting modernos como Bash, siempre he preferido la convención de los nombres en minúsculas para las variables temporales, y en mayúsculas solo para las variables exportadas (es decir, el entorno) . Por ejemplo:

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

Esa siempre ha sido mi opinión sobre las cosas. ¿Hay alguna fuente autorizada que esté de acuerdo o en desacuerdo con este enfoque, o es puramente una cuestión de estilo?

Por convención, las variables de entorno ( PAGER , EDITOR , …) y las variables internas de shell ( SHELL , BASH_VERSION , …) están en mayúscula. Todos los demás nombres de variables deben estar en minúsculas.

Recuerde que los nombres de las variables distinguen entre mayúsculas y minúsculas; esta convención evita anular accidentalmente las variables ambientales e internas.

Siguiendo esta convención, puede estar seguro de que no necesita conocer todas las variables de entorno utilizadas por las herramientas o shells de UNIX para evitar sobrescribirlas. Si es tu variable, minúscala. Si lo exporta, en mayúscula.

Cualquier convención de nombres seguida consistentemente siempre ayudará. Aquí hay algunos consejos útiles para nombrar variables de shell:

  • Use todas las mayúsculas y los guiones bajos para las variables y constantes exportadas, especialmente cuando se comparten en varios scripts o procesos. Use un prefijo común cuando corresponda para que las variables relacionadas se destaquen y no entren en conflicto con las variables internas de Bash, que son todas mayúsculas.

    Ejemplos:

    • Variables exportadas con un prefijo común: JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
    • Constantes: LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING
  • Utilice ” mayúsculas y minúsculas ” ( todas minúsculas y guiones bajos ) para todas las variables que tienen un solo guión o bloque.

    Ejemplos: first_value max_amount num_errors

    Caso mixto cuando la variable local tiene alguna relación con una variable de entorno, como: old_IFS old_HOME

  • Use un guion bajo para variables y funciones “privadas”. Esto es especialmente relevante si alguna vez escribe una biblioteca de shell donde las funciones dentro de un archivo de biblioteca o entre archivos necesitan compartir variables, sin chocar con nada que pueda ser nombrado de manera similar en el código principal.

    Ejemplos: _debug _debug_level _current_log_file

  • Evita el estuche de camello . Esto minimizará los errores causados ​​por los errores tipográficos. Recuerde, las variables de shell son sensibles a mayúsculas y minúsculas

    Ejemplos: inputArray thisLooksBAD , numRecordsProcessed , veryInconsistent_style


Ver también:

  • Las especificaciones de base de grupo abierto, número 7: variables de entorno

Hago lo que haces. Dudo que haya una fuente autorizada, pero parece ser un estándar de facto bastante extendido.

Es solo una convención ampliamente celebrada, dudo que haya una fuente “autorizada” para ello.

En realidad, el término “variables de entorno” parece ser de acuñación bastante reciente. Kernighan y Pike en su libro clásico “El entorno de progtwigción UNIX”, publicado en 1984, hablan solo de “variables de caparazón”: ¡ni siquiera hay una entrada para “medio ambiente” en el índice!

utilizo ALL_CAPS tanto para el entorno como para las variables globales. por supuesto, en Bash no existe un ámbito variable real, por lo que hay una buena porción de variables utilizadas como globales (principalmente configuraciones y seguimiento de estado), y relativamente pocos “locales” (contadores, iteradores, cadenas parcialmente construidas y temporales)