修正Bash和shell脚本可变大小写

我遇到了很多带有全部大写变量的shell脚本,我一直认为这是一个严重的误解。 我的理解是,按照惯例(可能很久以前也是如此), 环境变量是全部大写的。

但在像Bash这样的现代脚本环境中,我一直倾向于使用临时变量的小写名称的惯例,而对于导出的变量(即环境变量)则使用大写的名称。 例如:

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

这一直是我的事情。 是否有任何权威人士同意或不同意这种方法,还是纯粹是一种风格问题?


按照惯例,环境变量( PAGEREDITOR ,...)和内部shell变量( SHELLBASH_VERSION ,...)都被大写。 所有其他变量名称应该是小写字母。

请记住,变量名称区分大小写; 这一惯例避免了意外覆盖环境和内部变量。

遵循这个约定,您可以放心,您不需要知道UNIX工具或shell使用的每个环境变量,以避免覆盖它们。 如果它是你的变量,小写它。 如果你输出它,大写。


任何遵循一致的命名约定总是会有所帮助。 以下是一些有关shell变量命名的有用提示:

  • 对导出的变量和常量使用全部大写和下划线 。 适用时使用通用前缀,以便相关变量脱颖而出。

    例子:

  • 使用公共前缀导出的变量: JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
  • 常量: PI MAX_FILES OK ERROR WARNING
  • 使用“蛇情况”( 全部为小写和下划线 )表示范围为单个脚本或块的所有变量。

    示例: input_file first_value max_amount num_errors

    当局部变量与环境变量有某种关系时会出现混合情况,如: old_IFS old_HOME

  • 对“私人”变量和函数使用前导下划线 。 如果您编写的库函数在库文件或跨文件需要共享变量的情况下运行,而不会与主代码中可能类似命名的任何内容冲突,那么这尤其相关。

    示例: _debug _debug_level _current_log_file

  • 永远不要使用骆驼案件 。 这将确保我们不会遇到由案例错误造成的错误。 请记住,shell变量是区分大小写的

    示例: inputArray thisLooksBADnumRecordsProcessedveryInconsistent_style


  • 也可以看看:

  • 开放组织基本规范问题7 - 环境变量

  • 我做你所做的事。 我怀疑有一个权威来源,但它似乎是一个相当普遍的事实标准。

    链接地址: http://www.djcxy.com/p/25569.html

    上一篇: Correct Bash and shell script variable capitalization

    下一篇: Setting environment variables in OS X?