Por que o Windows não pode manipular uma variável de ambiente no Path?

Question

Meu colega e eu temos estações de trabalho Dell idênticas com o Windows XP Professional x64 edition instalado.

A variável de ambiente My Path começa com:

%JAVA_HOME%\bin;...

A variável Path do meu colega inclui o mesmo diretório, especificado usando a mesma variável de ambiente, mas não é o primeiro item em seu caminho.

Se eu acessar as propriedades do sistema - > variáveis de ambiente e altere o valor da minha variável JAVA_HOME, a versão do java encontrada a partir das alterações da linha de comandos conforme o esperado. Isso está iniciando uma nova janela do console, para garantir as alterações.

Mas na máquina do meu colega, isso não acontece. Ele continua a encontrar sua versão anterior do Java até que ele exiba sua variável Path e a salve (mesmo que não faça alterações nela). (Mais uma vez, é quando se inicia uma nova janela de console.)

Eu tenho observado essa inconsistência no Windows há cerca de 6 meses e estou muito curioso sobre isso. Temos muitas versões do Windows em nosso escritório, então raramente tive a chance de ver isso acontecendo em duas máquinas executando exatamente a mesma versão do sistema operacional, até agora.

O que está causando isso? Por que sua máquina não reavalia o Path, usando o novo JAVA_HOME, quando o meu faz?

(É porque não é a primeira coisa no Caminho? Se sim, como poderia ser, e por quê? Eu faria mais testes para checar, mas acho que ele agora está farto disso e gostaria de ter de volta ao trabalho.)

    

Answer 1

Seu caminho é a concatenação do caminho do sistema seguido pelo caminho do usuário. Além disso, as variáveis de ambiente do sistema podem não conter referências a variáveis de ambiente do usuário, e tais referências não serão não expandidas. Para obter o resultado desejado, insira a referência a% JAVA_HOME% na variável de ambiente user PATH ou crie uma variável, se ainda não existir.

Talvez um exemplo simplificado torne isso mais claro. Suponha que o ambiente SYSTEM seja

ProgramFiles = C:\Program Files
SystemRoot = C:\WINDOWS
PATH = %SystemRoot%\SYSTEM32

e o ambiente do usuário JSmith é

JAVA_HOME = %ProgramFiles%\Java\bin
USERPROFILE = C:\USERS\JSmith
PATH = %JAVA_HOME%\bin;%USERPROFILE%\bin

então o caminho resultante seria

C:\WINDOWS\SYSTEM32;C:\Program Files\Java\bin;C:\Users\JSmith\bin

conforme desejado.

    

Answer 2

Verifique no registro do Windows sob esta chave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment

SE a variável de ambiente precisar ser expandida (aqui:% JAVA_HOME%)

então a variável deve ser definida como um valor REG_EXPAND_SZ .

Se estiver usando o reg.exe via linha de comando para adicionar / editar valores do registro, o padrão é digitar REG_SZ. Especifique o tipo REG_EXPAND_SZ usando a opção reg add /t REG_EXPAND_SZ .

    

Answer 3

Existe um problema definido na expansão de variáveis de ambiente dentro da variável PATH quando a variável se expande para um caminho que contém espaços.

Criamos nossas próprias variáveis de nível de sistema como "OUR_ROOT = c: \ MyRoot" e, em seguida, usamos no sistema PATH como "PATH =;% OUR_ROOT% \ bin;" e isso é expandido corretamente para "PATH =; c: \ MyRoot \ bin;". Até agora não há problema.

Mas, no Windows 7 (32 bits), eu mesmo tive uma instalação do produto e criei variáveis de ambiente do sistema como esta:

STUDIO_BIN=C:\program files\Company Name\Product Name 10.4\bin

e adicionou-o à variável PATH do sistema:

PATH=<other path elements>;%STUDIO_BIN%;<more path elements>

Mas os valores PATH mostrados no CMD continham "% STUDIO_BIN%;" e não o caminho expandido. O valor em Meu computador > Propriedades > Avançado > Env.Vars permaneceu não expandido também. Isso significa que não consegui executar programas que exigiam uma DLL nesse diretório.

Apenas alterando STUDIO_BIN (via Meu computador > Propriedades > Avançado ... > Env Vars) para um nome sem espaços incorporados:

STUDIO_BIN=C:\ProductName\bin

e, em seguida, reiniciar a janela do CMD, o PATH é agora:

PATH=<other path elements>;C:\ProductName\bin;<more path elements>

Outra solução é editar suficientemente a variável de sistema que você está usando no PATH usando o Meu computador > Propriedades > Avançado ... > Caixa de diálogo Variáveis de ambiente. Eu tentei adicionar um caractere e removê-lo para fazer uma 'alteração' e, em seguida, OK fora, iniciou um novo prompt CMD e PATH não foi expandido corretamente. Eu tentei deletar parte do caminho, então era

STUDIO_BIN=C:\Program Files\Company Name

(omitindo "Product Name 10.4") e eis que o próximo prompt CMD mostrou PATH com STUDIO_BIN devidamente expandido!

Curiosamente, se eu voltasse e adicionasse o "Product Name 10.4" ao STUDIO_BIN (incluindo todos os espaços que estavam originalmente lá antes de começar a mexer com ele) e o PATH AINDA estava expandido corretamente.

Evidentemente, com mudanças suficientes em seu conteúdo, a variável PATH passa por algum processamento extra na caixa de diálogo Variáveis de ambiente que permite que ele funcione. O processamento não é feito quando a variável foi adicionada pelo instalador do produto (o que provavelmente modificou o PATH diretamente no registro).

Estou quase certo de que este foi um problema com o XP também. Apenas ressurgiu para mim no Windows 7 quando eu estava montando uma nova máquina de desenvolvimento. Aparentemente, não foi corrigido pela Microsoft.

Aparentemente, mesmo variáveis definidas pelo MS como% ProgramFiles% não serão expandidas corretamente no PATH.

Esta página fornece uma resposta possível se você estiver definindo o PATH por meio da linha de comando ou do arquivo em lote. (Coloque o comando inteiro após o SET entre aspas). Eu não sei qual instalador o produto que eu instalei usava para definir as variáveis de ambiente, mas ele evidentemente passou por qualquer processamento necessário para expandir adequadamente os caminhos com espaços.

Então, para resumir, você pode:

• altere os caminhos (e mova todos os arquivos associados) para caminhos sem espaços ou

• edite as variáveis que não estão conseguindo expandir na caixa de diálogo Variáveis de ambiente (alterando-as o suficiente para processá-las corretamente - não estou certo de quanto é suficiente).

Answer 4

Eu perguntei isso nos fóruns da Microsoft em março de 2009 e nunca consegui resolver:

Como usar% ProgramFiles% no caminho variável de ambiente? :

Estou tentando adicionar uma pasta ao variável de ambiente Path do sistema.

Eu quero adicionar % ProgramFiles% \ SysInternals

para a variável de caminho existente:

C:\PROGRA~1\Borland\Delphi5\Projects\Bpl;C:\PROGRA~1\Borland\Delphi5\Bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Microsoft SQL Server\Tools\BINN;C:\Program Files\Microsoft SQL Server\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Tools\binn\;C:\Program Files\Microsoft SQL Server\DTS\Binn\;C:\Program Files\Microsoft SQL Server\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

Então eu vou para o lugar onde você o edita:

Eeuadicionominhavariávelaocaminho:

%ProgramFiles%\SysInternals;C:\PROGRA~1\Borland\Delphi5\Projects\Bpl;(snip)

Emseguida,abrirumnovopromptdecomandojanelaavariáveldeambientenãoésubstituídopeloseuvalorreal:

Path=%ProgramFiles%\SysInternals;C:\PROGRA~1\Borland\Delphi5\Projects\Bpl(snip)>

Quevocêpodevernaseguintecapturadetela:

Mas para responder à sua pergunta: não sei. Parece que não pode ser feito.

    

Answer 5

existem dois níveis de variáveis de ambiente, global e usuário. Se ele tiver% Java_home% definido como uma variável de ambiente do usuário, mas mudando o global, ele não verá nenhuma diferença.

    

Answer 6

Certifique-se de que não haja espaços no PATH ao definir suas próprias variáveis de ambiente do usuário. eg: C: \ GNAT \ bin; C: \ GNAT \ include não funciona, por causa do espaço entre o ";" e "C: \ GNAT \ include".

    

Answer 7

Adicione as variáveis de ambiente enquanto estiver logado na sessão / console usando o MSTSC.

Reinicialize a máquina e você verá que suas variáveis de ambiente terão persistido.

Parece haver uma peculiaridade no O / S, dependendo de como você estava conectado à máquina quando tentou alterar a variável de ambiente.

    

Answer 8

Pode estar relacionado ao recurso "expansão de variável de ambiente atrasada" (ou falta dela), ou talvez você possa aproveitar esse recurso para ter sempre uma solução correta.

de um prompt de cmd

set /? 

e leia a seção que descreve "expansão de variável de ambiente atrasada", que inclui um pequeno exemplo para testar

set VAR=before
if "%VAR%" == "before" (
    set VAR=after
    if "%VAR%" == "after" @echo If you see this, it worked
)

Se você não obtiver a linha de eco, isso pode explicar ...

Se, no entanto, você iniciar o cmd.exe com a opção / V, poderá usar "!" em vez de "%", que muda o comportamento

set VAR=before
if "%VAR%" == "before" (
    set VAR=after
    if "!VAR!" == "after" @echo If you see this, it worked
)

Para mim (rodando no XP), o primeiro script não funcionou, mas a segunda versão funcionou (com cmd.exe / V)

    

Answer 9

Eu tive o mesmo problema, e sei como consertar isso, o seu coxo.

Basta editar seu PATH novamente, mas não faça alterações e salve novamente o PATH. Por algum motivo, isso faz com que todas as referências de variáveis de ambiente aninhadas sejam reavaliadas.

Se não funcionar, faça isso mais algumas vezes, de alguma forma, isso simplesmente funciona.

    

Answer 10

Eu acredito que o Windows não consegue expandir uma variável no PATH porque pensa o que não definiu ainda. Considere:

REM Ensure variable is undefined
SET UNDEFINED=
REM And then try to expand it
ECHO UNDEFINED=%UNDEFINED%

Esta hipótese está de acordo com minha outra observação - adicionar %ProgramFiles%\Something aos usuários PATH sempre resultará na expansão esperada de %ProgramFiles% , dado que foi definido no ambiente da máquina no momento de notificação de mudança de variável (ordem de carregamento devido - MACHINE e depois USER). Mas quando você modifica o ambiente da máquina, a expansão correta da variável só acontece no momento da inicialização (agora eu não tenho idéia como e por que isso não acontece regularmente.

    

Answer 11

Talvez você esteja fazendo errado?

Eu tentei com o Windows XP Pro SP3 (32 bits). Eu tenho um caminho com várias ocorrências de %JAVA_HOME% (e %JAVAFX_HOME% , etc.). Eu vou para a linha de comando, digite PATH , vejo as variáveis expandidas. Bom.

Eu mudo o valor de JAVA_HOME . Voltar para a mesma janela de linha de comando, PATH novamente, mesmo valor ... como esperado (por experiência!).

Eu abro uma nova janela de linha de comando, digite PATH , gotcha, vejo o novo valor.

Não sei qual é o mecanismo exato lá, mas parece que qualquer programa em execução, incluindo o cmd.exe, captura os valores das variáveis de ambiente na hora de início e não olha para trás ... (embora eu acredite que um bom O programa comportado pode escutar alterações de env, embora não muito certo).

Pode ser visto como um recurso ou um bug ou aborrecimento, mas é assim que funciona. Ei, pelo menos, ao contrário do Win9X vezes, não temos que reiniciar o computador! E, ao contrário dos tempos do NT (IIRC), você não precisa sair e voltar.

Por que a inconsistência? Os caminhos da Microsoft são inescrutáveis ... :-P

    

Answer 12

PATH é a concatenação da variável PATH do usuário seguida pela variável PATH global. Para usar uma variável dentro de outra, a primeira já deve estar definida. As variáveis do usuário são definidas antes das variáveis globais (pelo menos aqui no meu Windows 7 de 64 bits), portanto, você não pode usar variáveis globais na variável PATH do usuário. Além disso, as variáveis são definidas em ordem alfabética, portanto você também deve ter isso em mente.

    

Answer 13

Eu resolvi configurar as variáveis de ambiente em Sistema > Configurações avançadas > Variáveis de ambiente .

Há dois painéis, User e Global variables (usuário é seu nome de usuário do Windows) e System Variables são variáveis globais, então se você definir 'New' de variáveis User, como JAVA_HOME e colocar seu caminho abaixo, você irá definir variáveis mesmo se o seu caminho global tiver arquivos de programa dentro da pasta.