The ^ operator converts to uppercase, while , converts to lowercase. If you double-up the operators, ie, ^^ or ,, , it applies to the whole string; otherwise, it applies only to the first letter (that isn't absolutely correct - see "Advanced Usage" below - but for most uses, it's an adequate description).
Bash also supports some basic type declaration using the declare option, and bash variables are case sensitive.
Do not capitalize effects or variables unless they appear with multiplication signs. Many authors confuse these terms (factor, variable, and effect), and if you are uncertain about whether the author used them correctly, it is best to query.
By convention, environment variables (PAGER
, EDITOR
, ...) and internal shell variables (SHELL
, BASH_VERSION
, ...) are capitalized. All other variable names should be lower case.
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.
Any naming conventions followed consistently will always help. Here are a few helpful tips for shell variable naming:
Use all caps and underscores for 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 variables which are all upper case.
Examples:
JOB_HOME
JOB_LOG
JOB_TEMP
JOB_RUN_CONTROL
LOG_DEBUG
LOG_INFO
LOG_ERROR
STATUS_OK
STATUS_ERROR
STATUS_WARNING
Use "snake case" (all lowercase and underscores) for all variables that are scoped to a single script or a block.
Examples: input_file
first_value
max_amount
num_errors
Use mixed case when local variable has some relationship with an environment variable, like: old_IFS
old_HOME
Use a leading underscore for "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: inputArray
thisLooksBAD
, numRecordsProcessed
, veryInconsistent_style
See also:
If shell variables are going to be exported to the environment, it’s worth considering that the POSIX (Issue 7, 2018 edition) Environment Variable Definition specifies:
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.
...
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.
I do what you do. I doubt there's an authoritative source, but it seems a fairly widespread de-facto standard.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With