Is it a bad practice to have a dollar sign in an environment variable's value?
ex:
MY_VAR="$toto"
To be more precise, I would like to set it in the /etc/environment file to be accessible by a java program. I did a test and it's working but I just want to make sure I won't encounter any catastrophic side effect.
The value of the variable is a password and starts with a dollar sign so I have no choice.
4 Answers
Your example does not illustrate your question.
$ toto="somevalue"
$ MY_VAR="$toto"
$ echo $MY_VAR
somevalue
$
To do what you asked, you'd need:
MY_VAR='$toto'
or
MY_VAR="\$toto"
Can't tell for sure if it's bad practice. Personally I don't see any obvious problem.
Many pointed out that MY_VAR="$toto" will assign to MY_VAR the current value of $toto or an empty string in case $toto is unset (or in case $toto itself contains an empty string obviously), but I'm surprised no one pointed out yet that MY_VAR="$toto" will not set an environment variable but rather a shell variable (unless a variable named MY_VAR is already present in the environment, perhaps because this is only tangential to the actual question).
However more to the point no, it's not a bad practice, or it's just as bad practice as having any other shell special character inside a variable, which is often not avoidable.
In 99% of the cases the shell will expand the variable in the current shell only once (or will not expand it at all for example when enclosed in single-quotes):
$ MY_VAR='$toto'
$ echo $MY_VAR
$toto
$ echo '$MY_VAR'
$MY_VAR
$ echo "$MY_VAR"
$toto
$ echo $(echo $MY_VAR)
$toto
The 1% of the cases being, for example, when the variable is referenced in an eval expression, which adds a level of indirection:
$ MY_VAR='$toto'
$ eval echo $MY_VAR
$
But that's obviously the expected result, and again, then having any other shell special character inside a variable should be considered a bad practice in the same way:
$ MY_VAR='&&'
$ eval echo $MY_VAR
bash: syntax error: unexpected end of file
(the truth being that using eval is often a bad practice, for this very reason).
So no, having a dollar sign in a shell / environment variable is not a bad practice, at least not more than having any other shell special character.
For the specific case of /etc/environment, no, a $ in the variable value doesn't mean anything special. /etc/environment is a file read by a PAM module named pam_env, and pam_env has specific syntax for interpreting $:
- In
/etc/environment, it is left uninterpreted. In
/etc/security/pam_env.confand~/.pam_environment(a user-specific file),pam_envtreats$specially when it sees lines with the following syntax:FOO DEFAULT=SOMETHING${BAR}SOMETHINGELSE$BAR FOO OVERRIDE=SOMETHING${BAR}SOMETHINGELSE$BARIn this case,
${BAR}is replaced with the value of the variableBAR, but not$BAR.
In both cases, for a line like:
FOO=BAR$BAR${BAR}
The contents of the variable FOO will be the literal string BAR$BAR${BAR}.
The pam_env.conf manpage has examples:
Silly examples of escaped variables, just to show how they work.
DOLLAR DEFAULT=\$
DOLLARDOLLAR DEFAULT= OVERRIDE=\$${DOLLAR}
DOLLARPLUS DEFAULT=\${REMOTEHOST}${REMOTEHOST}
ATSIGN DEFAULT="" OVERRIDE=\@
To answer your exact question:
Yes, it is bad practice to have a dollar sign in the value of an environment variable. However, that's not what the code snippet you have displayed actually does.
MY_VAR="$toto"
$ is a special character to your shell (whether bash or dash), and unless protected against variable expansion, you won't actually be putting a literal dollar sign in the value of MY_VAR.
To do that you would need to escape the $, either with a backslash just before it, or single quotes around it.
