我遇到了许多带有变量的shell脚本,我一直认为存在严重的误解.我的理解是,按照惯例(也许很久以前就必须),环境变量都是全部的.
但是在像Bash这样的现代脚本环境中,我总是倾向于使用临时变量的小写名称约定,而仅为导出(即环境)变量使用大写的约定.例如:
#!/usr/bin/env bash year=`date +%Y` echo "It is $year." export JAVA_HOME="$HOME/java"
这一直是我对事物的看法.是否有任何权威来源同意或不同意这种方法,还是纯粹是风格问题?
按照惯例,环境变量(PAGER
,EDITOR
,...)和内部shell变量(SHELL
,BASH_VERSION
,...)都大写.所有其他变量名称应为小写.
请记住,变量名称区分大小写; 该惯例避免意外地覆盖环境和内部变量.
遵守此约定,您可以放心,您不需要知道UNIX工具或shell使用的每个环境变量,以避免覆盖它们.如果它是你的变量,则小写它.如果您将其导出,请将其大写.
任何遵循的命名约定始终有用.以下是shell变量命名的一些有用提示:
对导出的变量和常量使用全部大写和下划线,尤其是在跨多个脚本或进程共享它们时.在适用的时候使用公共前缀,以便相关变量突出,并且不会与全部大写的Bash内部变量冲突.
例子:
导出的变量具有公共前缀: 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
也可以看看:
开放组基础规范第7期 - 环境变量
我做你做的.我怀疑这是一个权威来源,但它似乎是一个相当普遍的事实上的标准.
如果要将shell变量导出到环境中,则值得考虑的是POSIX(第7版,2018年版)环境变量定义指定:
POSIX.1-2017的Shell and Utilities卷中的实用程序使用的环境变量名称仅由大写字母,数字和
_
可移植字符集中定义的字符中的下划线()组成,并且不能以数字开头。
...
包含小写字母的环境变量名称的名称空间保留给应用程序。应用程序可以使用此名称空间中的名称定义任何环境变量,而无需修改标准实用程序的行为。