正确的 Bash 和 shell 脚本变量大小写

Correct Bash and shell script variable capitalization

提问by JasonSmith

I run across many shell scripts with variables in all caps, and I've always thought that there is a severe misunderstanding with that. My understanding is that, by convention (and perhaps by necessity long ago), environment variablesare in all-caps.

我遇到了许多变量全部大写的 shell 脚本，我一直认为对此存在严重的误解。我的理解是，按照惯例（也许很久以前是必要的），环境变量都是大写的。

But in modern scripting environments like Bash, I have always preferred the convention of lower-case names for temporary variables, and upper-case ones only for exported (i.e. environment) variables. For example:

但是在像 Bash 这样的现代脚本环境中，我总是倾向于将小写名称用于临时变量，而大写名称仅用于导出（即环境）变量。例如：

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

That has always been my take on things. Are there any authoritative sources which either agree or disagree with this approach, or is it purely a matter of style?

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

回答by lhunath

By convention, environment variables (PAGER, EDITOR, ...) and internal shell variables (SHELL, BASH_VERSION, ...) are capitalized. All other variable names should be lower case.

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

Remember that variable names are case-sensitive; this convention avoids accidentally overriding environmental and internal variables.

请记住，变量名称区分大小写；这个约定避免了意外覆盖环境和内部变量。

Keeping to this convention, you can rest assured that you don't need to know every environment variable used by UNIX tools or shells in order to avoid overwriting them. If it's your variable, lowercase it. If you export it, uppercase it.

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

回答by codeforester

Any naming conventions followed consistently will always help. Here are a few helpful tips for shell variable naming:

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

• Use all caps and underscoresfor exported variables and constants, especially when they are shared across multiple scripts or processes. Use a common prefix whenever applicable so that related variables stand out and won't clash with Bash internal variableswhich are all upper case.

  Examples:

  • Exported variables with a common prefix: JOB_HOMEJOB_LOGJOB_TEMPJOB_RUN_CONTROL
  • Constants: LOG_DEBUGLOG_INFOLOG_ERRORSTATUS_OKSTATUS_ERRORSTATUS_WARNING

• Use "snake case" (all lowercase and underscores) for all variables that are scoped to a single script or a block.

  Examples: input_filefirst_valuemax_amountnum_errors

  Use mixed case when local variable has some relationship with an environment variable, like: old_IFSold_HOME

• Use a leading underscorefor "private" variables and functions. This is especially relevant if you ever write a shell library where functions within a library file or across files need to share variables, without ever clashing with anything that might be similarly named in the main code.

  Examples: _debug_debug_level_current_log_file

• Avoid camel case. This will minimize the bugs caused by case typos. Remember, shell variables are case sensitive.

  Examples: inputArraythisLooksBAD, numRecordsProcessed, veryInconsistent_style

• 对导出的变量和常量使用全部大写和下划线，尤其是当它们在多个脚本或进程之间共享时。在适用时使用公共前缀，以便相关变量脱颖而出，并且不会与Bash 内部变量（都是大写的）发生冲突。

  例子：

  • 具有公共前缀的导出变量： JOB_HOMEJOB_LOGJOB_TEMPJOB_RUN_CONTROL
  • 常数： LOG_DEBUGLOG_INFOLOG_ERRORSTATUS_OKSTATUS_ERRORSTATUS_WARNING

• 对作用域为单个脚本或块的所有变量使用“蛇形大小写”（全部小写和下划线）。

  例子： input_filefirst_valuemax_amountnum_errors

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

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

  例子： _debug_debug_level_current_log_file

• 避免驼峰事件。这将最大限度地减少由大小写错别字引起的错误。请记住，shell 变量区分大小写。

  例子：inputArraythisLooksBAD, numRecordsProcessed,veryInconsistent_style

---

---

See also:

也可以看看：

• The Open Group Base Specifications Issue 7 - Environment Variables

• The Open Group 基本规范问题 7 - 环境变量

回答by Anthony Geoghegan

If shell variables are going to be exported to the environment, it's worth considering that the POSIX (Issue 7, 2018 edition) Environment Variable Definitionspecifies:

如果要将 shell 变量导出到环境中，则值得考虑 POSIX（2018 年第 7 期）环境变量定义指定：

Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2017 consist solely of uppercase letters, digits, and the underscore ( _) from the characters defined in Portable Character Set and do not begin with a digit.

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

...

...

The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.

包含小写字母的环境变量名称的命名空间是为应用程序保留的。应用程序可以使用该命名空间中的名称定义任何环境变量，而无需修改标准实用程序的行为。

回答by Draemon

I do what you do. I doubt there's an authoritative source, but it seems a fairly widespread de-facto standard.

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

回答by Draemon

Actually, the term "environment variables" seems to be of fairly recent coinage. Kernighan and Pike in their classic book "The UNIX Programming Environment", published in 1984, speak only of "shell variables" - there is not even an entry for "environment" in the index!

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

回答by Alnitak

It's just a very widely held convention, I doubt there's any "authoritative" source for it.

这只是一个非常广泛举行的会议，我怀疑它是否有任何“权威”来源。

回答by Javier

i tend use ALL_CAPS both for environment and global variables. of course, in Bash there's no real variable scope, so there's a good portion of variables used as globals (mostly settings and state tracking), and relatively few 'locals' (counters, iterators, partly-constructed strings, and temporaries)

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