我遇到了许多带有变量的shell脚本，我一直认为存在严重的误解。我的理解是，按照惯例（可能很久以前必需），环境变量都是全部大写。
但是在像Bash这样的现代脚本环境中，我总是倾向于使用临时变量的小写名称约定，而仅为导出（即环境）变量的大写约定。例如：
#!/usr/bin/env bash
year=`date +%Y`
echo "It is $year."
export JAVA_HOME="$HOME/java"
这一直是我对事物的看法。是否有任何权威来源同意或不同意这种方法，还是纯粹是风格问题？
答案 0 :(得分：221)
按照惯例，环境变量（PAGER，EDITOR，...）和内部shell变量（SHELL，BASH_VERSION，...）都是大写的。所有其他变量名称应为小写。
请记住，变量名称区分大小写;这个惯例避免意外地覆盖环境和内部变量。
遵守此约定，您可以放心，您不需要知道UNIX工具或shell使用的每个环境变量，以避免覆盖它们。如果它是你的变量，则小写它。如果您将其导出，请将其大写。
答案 1 :(得分：17)
遵循的任何命名约定始终有用。以下是shell变量命名的一些有用提示：
对导出的变量和常量使用全部大写和下划线，尤其是当它们在多个脚本或进程中共享时。在适用的时候使用通用前缀，以便相关变量脱颖而出，并且不会与Bash internal variables发生冲突，这些变量都是大写。
示例：
JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING 对所有限定为单个脚本或块的变量使用“snake case”（全部小写和下划线）。
示例：input_file first_value max_amount num_errors
当局部变量与环境变量有某种关系时的混合情况，例如：old_IFS old_HOME
对“私有”变量和函数使用前导下划线。如果您编写一个shell库，其中库文件中的函数或文件中的函数需要共享变量，而不会与主代码中可能类似命名的任何内容发生冲突，这一点尤为重要。
示例：_debug _debug_level _current_log_file
避免骆驼案例。这将最大限度地减少由错别字引起的错误。请记住，shell变量区分大小写。
示例：inputArray thisLooksBAD，numRecordsProcessed，veryInconsistent_style
另见：
答案 2 :(得分：6)
我做你做的。我怀疑这是一个权威来源，但它似乎是一个相当普遍的事实上的标准。
答案 3 :(得分：3)
这只是一个非常广泛的会议，我怀疑它有任何“权威”来源。
答案 4 :(得分：3)
实际上，“环境变量”这个词似乎是最新造币。 Kernighan和Pike在1984年出版的经典着作“UNIX编程环境”中只谈到“shell变量” - 索引中甚至没有“环境”条目！
答案 5 :(得分：3)
如果要将外壳变量导出到环境中，则值得考虑的是POSIX（2018年第7期，版本）Environment Variable Definition指定：
命令行管理程序和实用程序中的实用程序使用的环境变量名称 POSIX.1-2017的卷仅包含大写字母，数字和 在可移植字符集中定义的字符下划线（
_） 并且不要以数字开头。
...
包含小写字母的环境变量名称的名称空间为 保留给应用程序。应用程序可以定义任何环境变量 使用此名称空间中的名称，而无需修改 标准实用程序。
答案 6 :(得分：1)
我倾向于将ALL_CAPS用于环境变量和全局变量。当然，在Bash中没有真正的变量范围，所以有很多变量用作全局变量（主要是设置和状态跟踪），而且相对较少的'locals'（计数器，迭代器，部分构造的字符串和临时变量）
答案 7 :(得分：0)
Bash 和大多数 shell 脚本解释器识别函数内的全局和局部变量（例如排版、声明、本地），并应适当使用。如前所述，“POSIX.1-2017 的 Shell 和实用程序卷中的实用程序使用的环境变量名称仅由大写字母、数字和来自可移植字符集中定义的字符的下划线 (_) 组成，并且不以带有数字。......包含小写字母的环境变量名称的命名空间是为应用程序保留的。应用程序可以使用此命名空间中的名称定义任何环境变量，而无需修改标准实用程序的行为。” (POSIX IEEE Std 1003.1-2008 section 8.1 )