Parece que você não fez isso corretamente.
Eu suspeito que você está tentando fazer a terceira coisa, mas usando sintaxe errada. Cinco erros comuns que podem produzir erros como o que você está vendo são:
Usando espaços em vez de =
. export NAME value
está incorreto; value
é então interpretado como o nome de uma variável subsequente a ser exportada.
(Isso acontece porque export NAME1 NAME2
é a sintaxe correta para exportar várias variáveis.)
Colocando espaços ao redor =
. Em muitas linguagens de programação, é válido e estilisticamente preferido ocupar os operadores com espaços a maior parte do tempo. Mas, para atribuir um valor a uma variável em um script de shell (ou outra situação em que você esteja emitindo comandos de shell), isso não é permitido. NAME = value
(em um export
comando ou não) não funcionará; você deve usar NAME=value
.
( export NAME = value
Tenta variáveis de exportação chamado NAME
, =
e value
. Felizmente isso nunca parece ter sucesso em silêncio, porque a tentativa de exportar uma variável chamada =
é um erro de sintaxe. Em contraste export NAME= value
aparecerá ao trabalho, mas não atribui value
a NAME
--instead, ele atribui o vazio, cadeia de comprimento zero para NAME
e exporta-a e exporta separadamente a variável value
. Ambos são erros comuns.)
Separando partes do valor da variável com espaços. As variáveis de ambiente podem conter espaços, mas na prática raramente são usadas como separadores de campo em variáveis de ambiente. Quando uma única variável contém intencionalmente vários caminhos, geralmente :
é usada para separá-los.
Não citando espaços ao atribuir a variáveis. Às vezes, o valor de uma variável de ambiente deve conter um espaço. Por exemplo, pode ser o nome de um diretório que realmente contém um espaço. Nesse caso, é necessário citar qualquer espaço.
Uma maneira de fazer isso é precedê-los \
. Consulte Como proteger parênteses passados para um comando cd? e Não é possível excluir o arquivo para obter informações de outras maneiras - os métodos apresentados nas respostas se aplicam, mesmo que nenhuma pergunta seja especificamente sobre a atribuição a variáveis de ambiente.
Por exemplo, aqui estão algumas maneiras de exportar a variável de ambiente SILLYPATH
com o valor /home/ek/silly name/bin
:
export SILLYPATH=/home/ek/silly\ name/bin
export SILLYPATH='/home/ek/silly name/bin'
export SILLYPATH="/home/ek/silly name/bin"
Freqüentemente, quando uma pasta que você deve usar em um shell ou atribuir a uma variável de ambiente amplamente usada contiver um espaço, poderá ser renomeada. (Mas às vezes isso é impraticável ou indesejável.)
Atribuir e / ou exportar uma variável quando nada precisava ser feito. Isso é uma espécie de meta-erro; o problema técnico específico geralmente é um dos itens acima, mas a solução é livrar-se da linha ofensiva, ou de parte dela, em vez de corrigi-la. Não remova indiscriminadamente o código .bashrc
, é claro. Mas um export
pode ter sido adicionado acidentalmente ou, inadvertidamente, pode ter mais código do que o pretendido. Por exemplo, suponha que você quis escrever:
echo 'export PATH=~/some.bin:"$PATH"' >>~/.bashrc; . ~/.bashrc
Isso seria anexado e .bashrc
, em seguida, re-originado. Mas suponha que você tenha escrito:
echo 'export PATH=~/some.bin:"$PATH" . ~/.bashrc' >>~/.bashrc # WRONG!
Então, seu export
comando não apenas exportaria um valor aumentado de PATH
, mas também tentaria exportar variáveis nomeadas .
e , que não é o que você deseja. Como eles contêm caracteres proibidos em nomes de variáveis, você receberá um erro sempre que iniciar um novo shell bash interativo./home/your-username/.bashrc
Para evitar este problema, sugiro edição .bashrc
em um editor (por exemplo, nano ~/.bashrc
, gedit ~/.bashrc
), em vez de redireccionar a saída para o fim de tudo com >>
.