Sinal de dólar no valor da variável de ambiente

Question

É uma prática ruim ter um cifrão no valor de uma variável de ambiente?

ex:

MY_VAR="$toto"

Para ser mais preciso, gostaria de defini-lo no arquivo /etc/environment para ser acessível por um programa java. Eu fiz um teste e está funcionando, mas só quero ter certeza de que não encontrarei nenhum efeito colateral catastrófico. O valor da variável é uma senha e começa com um sinal de dólar, então não tenho escolha.

    

Answer 1

Para o caso específico de /etc/environment , não, um $ no valor da variável não significa nada de especial. /etc/environment é um arquivo lido por um módulo PAM chamado pam_env e pam_env tem uma sintaxe específica para interpretar $ :

1. Em /etc/environment , não é interpretado.

2. Em /etc/security/pam_env.conf e ~/.pam_environment (um arquivo específico do usuário), pam_env trata$ especialmente quando vê linhas com a seguinte sintaxe:

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

   Nesse caso, ${BAR} é substituído pelo valor da variável BAR , mas não $BAR .

Em ambos os casos, para uma linha como:

FOO=BAR$BAR${BAR}

O conteúdo da variável FOO será a string literal BAR$BAR${BAR} .

A% man_de% manpage tem exemplos:

Silly examples of escaped variables, just to show how they work.

         DOLLAR         DEFAULT=\$
         DOLLARDOLLAR   DEFAULT=        OVERRIDE=\$${DOLLAR}
         DOLLARPLUS     DEFAULT=\${REMOTEHOST}${REMOTEHOST}
         ATSIGN         DEFAULT=""      OVERRIDE=\@

    

Answer 2

Seu exemplo não ilustra sua pergunta.

$ toto="somevalue"
$ MY_VAR="$toto"
$ echo $MY_VAR
somevalue
$ 

Para fazer o que você pediu, você precisaria:

MY_VAR='$toto'

ou

MY_VAR="\$toto"

Não sei ao certo se é uma prática ruim. Pessoalmente, não vejo nenhum problema óbvio.

    

Answer 3

Muitos salientaram que MY_VAR="$toto" atribuirá a MY_VAR o valor atual de $toto ou uma string vazia no caso de $toto não ser definido (ou no caso de $toto conter uma string vazia obviamente), mas Estou surpreso que ninguém apontou ainda que MY_VAR="$toto" não definirá uma variável de ambiente, mas sim uma variável de shell (a menos que uma variável chamada MY_VAR já esteja presente no ambiente, talvez porque tangencial apenas à questão real).

No entanto, mais ao ponto não, não é uma prática ruim, ou é uma prática tão ruim quanto ter qualquer outro caractere especial de shell dentro de uma variável, o que muitas vezes não é evitável.

Em 99% dos casos, o shell expandirá a variável no shell atual somente uma vez (ou não a expandirá, por exemplo, quando colocado entre aspas simples):

$ MY_VAR='$toto'
$ echo $MY_VAR
$toto
$ echo '$MY_VAR'
$MY_VAR
$ echo "$MY_VAR"
$toto
$ echo $(echo $MY_VAR)
$toto

O 1% dos casos, por exemplo, quando a variável é referenciada em uma expressão eval , o que adiciona um nível de indireção:

$ MY_VAR='$toto'
$ eval echo $MY_VAR

$

Mas esse é obviamente o resultado esperado e, novamente, ter qualquer outro caractere especial de shell dentro de uma variável deve ser considerado uma prática ruim da mesma maneira:

$ MY_VAR='&&'
$ eval echo $MY_VAR
bash: syntax error: unexpected end of file

(a verdade é que usando eval é uma prática ruim, por essa razão).

Portanto, não, ter um sinal de dólar em uma variável shell / ambiente não é uma prática ruim, pelo menos não mais do que ter qualquer outro caractere especial de shell.

    

Answer 4

Para responder à sua pergunta exata:

Sim, é uma prática ruim ter um cifrão no valor de uma variável de ambiente. No entanto, não é isso que o snippet de código que você exibiu realmente faz.

MY_VAR="$toto"

$ é um caractere especial para o seu shell (seja bash ou dash ) e, a menos que esteja protegido contra expansão de variável, você não colocará realmente um sinal de dólar literal no valor de MY_VAR .

Para fazer isso, você precisa escapar do $ , seja com uma barra invertida logo antes ou com aspas simples ao redor dele.