正确Bash和shell脚本变量大写

我遇到过许多变量都是大写的shell脚本，我一直认为这是一个严重的误解。我的理解是，按照惯例(也许是很久以前的必要)，环境变量是全大写的。

但是在像Bash这样的现代脚本环境中，我总是更喜欢使用小写字母命名临时变量，而使用大写字母仅用于导出(即环境)变量。例如:

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

这一直是我对事物的看法。是否有任何权威来源同意或不同意这种方法，或者这纯粹是一个风格问题?

78912 次浏览
小开

这只是一个非常广泛的惯例，我怀疑是否有任何“权威”的来源。

小开

我做你做的事。我怀疑是否有一个权威的来源，但这似乎是一个相当普遍的事实标准。

小开

我倾向于对环境变量和全局变量都使用ALL_CAPS。当然，在Bash中没有真正的变量作用域，所以有相当一部分变量被用作全局变量(主要是设置和状态跟踪)，而相对较少的“局部变量”(计数器、迭代器、部分构造的字符串和临时变量)。

小开

实际上，“环境变量”这个术语似乎是最近才出现的。Kernighan和Pike在他们1984年出版的经典著作《UNIX编程环境》中，只提到了“shell变量”——在索引中甚至没有“环境”的条目!

小开
最佳答案

按照惯例，环境变量(PAGER， EDITOR，…)和内部shell变量(SHELL， BASH_VERSION，…)是大写的。所有其他变量名都应该小写。

记住变量名是区分大小写的;这种约定避免意外覆盖环境变量和内部变量。

按照这个约定，您可以放心，不需要知道UNIX工具或shell使用的每个环境变量，以避免覆盖它们。如果是变量，小写。如果要导出，请将其大写。

小开

始终遵循的命名约定总是有帮助的。下面是一些有用的shell变量命名技巧:

  • 对于导出的变量和常量使用全部大写和下划线，特别是当它们在多个脚本或进程中共享时。只要适用，就使用公共前缀，这样相关变量就会突出，不会与Bash内部变量冲突，因为Bash内部变量都是大写的。

    例子:

    • 导出具有公共前缀的变量:JOB_HOME JOB_LOG JOB_TEMP JOB_RUN_CONTROL
    • 常量:LOG_DEBUG LOG_INFO LOG_ERROR STATUS_OK STATUS_ERROR STATUS_WARNING
      • 李< / ul > < / >
    • 对于作用域为单个脚本或块的所有变量，使用“snake case”(全是小写字母和下划线)。

      例如:input_file first_value max_amount num_errors

      当局部变量与环境变量有某种关系时，使用混合大小写，例如:old_IFS old_HOME

    • 为“私有”变量和函数使用主要强调。如果您曾经编写过一个shell库，其中库文件中的函数或跨文件的函数需要共享变量，而不会与主代码中类似命名的任何内容发生冲突，那么这一点尤其重要。

      例如:_debug _debug_level _current_log_file

    • < p >避免驼峰式大小写。这将最大限度地减少大小写错别字引起的错误。记住，shell变量是区分大小写的。

      例如:inputArray thisLooksBAD， numRecordsProcessed， veryInconsistent_style

    参见:

小开

如果要将shell变量导出到环境中，值得考虑的是POSIX (Issue 7, 2018 edition) 环境变量定义指定:

Shell和utilities中实用程序使用的环境变量名称 卷POSIX.1-2017仅由大写字母，数字和 下划线(_)从可移植字符集中定义的字符 并且不要以数字开头。

.．.

包含小写字母的环境变量名称空间为 预留给应用程序。应用程序可以定义任何环境变量 类的行为 标准工具。< / p >

小开

Bash和大多数shell脚本解释器都可以识别函数中的全局变量和局部变量(例如typeset, declare, local)，并应酌情使用。如前所述，POSIX.1-2017的Shell和utilities卷中实用程序使用的环境变量名仅由大写字母、数字和来自可移植字符集中定义的字符的下划线(_)组成，并且不以数字. ...开头包含小写字母的环境变量名称空间为应用程序保留。应用程序可以用这个名称空间中的名称定义任何环境变量，而无需修改标准实用程序的行为。(POSIX IEEE Std 1003.1-2008第8.1节)

小开

ALL_CAP太丑陋的快速识别 !!!!!!!!!!!!!!!!!!!!!

为什么全大写的文本很难让用户阅读 裁判:https://uxmovement.com/content/all-caps-hard-for-users-to-read < / p >

对于我自己的配置，我使用任何我想要的:

  export XDG_CONFIG_HOME=$( realpath "$HOME/.config" )
export XDG_CACHE_HOME=$( realpath "$HOME/d/.cache_wf" )
export XDG_DATA_HOME=$( realpath "$HOME/.local/share" )


# 全部大写, 难辨认, 用这个:
export cfg_X=$XDG_CONFIG_HOME
export cache_X=$XDG_CACHE_HOME
export data_X=$XDG_DATA_HOME


[ -d "$cfg_X" ] || mkdir -m 0750 -p "$cfg_X"
[ -d "$cache_X" ]  || mkdir -m 0750 -p "$cache_X"
[ -d "$data_X" ]   || mkdir -m 0750 -p "$data_X"

(我更喜欢截图而不是粘贴文本，因为颜色和格式)

enter image description here


提交答案