10

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.

Kalle Richter
  • 6,519
jon
  • 203

4 Answers4

18

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.

Gunnar Hjalmarsson
  • 34,191
8

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.

kos
  • 41,268
3

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 $:

  1. In /etc/environment, it is left uninterpreted.

  2. In /etc/security/pam_env.conf and ~/.pam_environment (a user-specific file), pam_env treats $ specially when it sees lines with the following syntax:

    FOO DEFAULT=SOMETHING${BAR}SOMETHINGELSE$BAR
FOO OVERRIDE=SOMETHING${BAR}SOMETHINGELSE$BAR

    In this case, ${BAR} is replaced with the value of the variable BAR, 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=\@
muru
  • 207,228
2

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.

Wildcard
  • 1,260