it-swarm.it

Perché Windows non può gestire una variabile d'ambiente in Path?

Io e il mio collega abbiamo workstation Dell identiche con Windows XP Professional x64 edition installata.

La variabile d'ambiente My Path inizia con:

%Java_HOME%\bin;...

La variabile Path del mio collega include la stessa directory, specificata usando la stessa variabile d'ambiente, ma non è il primo oggetto nel suo percorso.

Se accedo alle proprietà di sistema -> variabili di ambiente e cambio il valore della mia variabile Java_HOME, la versione di Java trovata dalla riga di comando cambia come previsto. Si sta avviando una nuovissima finestra della console, per essere sicuri di raccogliere le modifiche.

Ma sulla macchina del mio collega, no. Continua a trovare la sua versione precedente di Java fino a quando non visualizza la sua variabile Path e la salva (anche se non apporta modifiche). (Di nuovo, questo è quando si avvia una nuova finestra della console.)

Ho osservato questa incoerenza su Windows per circa 6 mesi e ne sono molto curioso. Abbiamo troppe versioni di Windows nel nostro ufficio, così raramente ho avuto la possibilità di vederlo accadere su due macchine che eseguono esattamente la stessa versione del sistema operativo, fino ad ora.

Che cosa sta causando questo? Perché la sua macchina non rivaluta Path, usando la nuova Java_HOME, quando la mia fa?

(È perché non è la prima cosa nel Sentiero? Se sì, come potrebbe essere, e perché? Farei più test da controllare, ma penso che ora ne sia stufo e vorrebbe tornare al lavoro .)

43
skiphoppy

Il tuo percorso è la concatenazione del percorso di sistema seguito dal percorso dell'utente. Inoltre, le variabili di ambiente di sistema potrebbero non contenere riferimenti alle variabili di ambiente dell'utente e qualsiasi di questi riferimenti not sarà espanso. Per ottenere il risultato desiderato, inserire il riferimento su% Java_HOME% nella variabile d'ambiente utente PATH, o creare tale variabile se non esiste già .

Forse un esempio semplificato renderà questo più chiaro. Supponiamo che l'ambiente SYSTEM sia

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

e l'ambiente dell'utente JSmith è

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

allora il percorso risultante sarebbe

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

come desiderato.

37
JPaget

Controlla il registro di Windows sotto questa chiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment

Se la variabile di ambiente deve essere espansa (qui:% Java_HOME%)

quindi la variabile deve essere impostata come un valore REG_EXPAND_SZ .

Se si utilizza reg.exe tramite la riga di comando per aggiungere/modificare i valori del Registro di sistema, per impostazione predefinita digitare REG_SZ. Specificare il tipo REG_EXPAND_SZ utilizzando l'opzione reg add /t REG_EXPAND_SZ.

15
climenole

Esiste un problema preciso con l'espansione delle variabili di ambiente all'interno della variabile PATH quando la variabile si espande in un percorso che contiene spazi.

Abbiamo creato le nostre variabili a livello di sistema come "OUR_ROOT = c:\MyRoot" e poi l'ho usato nel PATH di sistema come "PATH =;% OUR_ROOT%\bin;" e che viene espanso correttamente in "PATH =; c:\MyRoot\bin;". Finora nessun problema.

Ma, su Windows 7 (32 bit), ho avuto l'installazione di un prodotto stesso e ho creato variabili di sistema come questa:

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

e lo ha aggiunto alla variabile PATH di sistema:

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

Ma i valori PATH mostrati in CMD contenevano "% STUDIO_BIN%;" e non il percorso espanso. Il valore in Risorse del computer> Proprietà> Avanzate> Env.Vars è rimasto non espanso. Ciò significava che non potevo eseguire programmi che richiedevano un DLL in quella directory.

Cambiando semplicemente STUDIO_BIN (tramite Risorse del computer> Proprietà> Avanzate ...> Env Vars) a un nome senza spazi incorporati:

STUDIO_BIN=C:\ProductName\bin

e quindi riavviare la finestra CMD, il PERCORSO è ora:

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

Un'altra soluzione è modificare a sufficienza la variabile di sistema che si sta utilizzando nel PERCORSO utilizzando la finestra di dialogo Risorse del computer> Proprietà> Avanzate ...> Variabili d'ambiente. Ho provato ad aggiungere un personaggio e rimuoverlo per fare un 'cambiamento' e poi OK, ho iniziato un nuovo prompt CMD e PATH NON è stato espanso correttamente. Ho quindi provato a eliminare parte del percorso così era

STUDIO_BIN=C:\Program Files\Company Name

(omettendo "Nome prodotto 10.4") ed ecco, il prossimo prompt CMD ha mostrato PATH con STUDIO_BIN espanso correttamente!

Stranamente, se tornassi indietro e aggiungessi "Product Name 10.4" a STUDIO_BIN (compresi tutti gli spazi che erano originariamente lì prima che iniziassi a usarlo) e PATH era ANCORA espanso correttamente.

Evidentemente con abbastanza modifiche ai suoi contenuti, la variabile PATH subisce alcune elaborazioni extra nella finestra di dialogo Variabili d'ambiente che gli permette di funzionare. L'elaborazione non viene eseguita quando la variabile è stata aggiunta dal programma di installazione del prodotto (che probabilmente ha modificato PATH direttamente nel registro).

Sono quasi sicuro che questo fosse un problema con XP pure. È appena riemerso per me in Windows 7 mentre stavo assemblando una nuova macchina di sviluppo. Apparentemente non è stato risolto da Microsoft.

Apparentemente anche le variabili definite da MS come% ProgramFiles% non si espanderanno correttamente nel PERCORSO.

Questa pagina fornisce una possibile risposta se si imposta PATH tramite la riga di comando o il file batch. (Racchiudere l'intero comando dopo SET tra virgolette.) Non so quale programma di installazione il prodotto che ho installato utilizzato per impostare le variabili di ambiente, ma evidentemente è andato in giro qualsiasi elaborazione è necessaria per espandere correttamente i percorsi con spazi.

Quindi, per riassumere, puoi:

  • cambiare i percorsi (e spostare tutti i file associati) in percorsi senza spazi, o

  • modifica le variabili che non riescono ad espandersi nella finestra di dialogo Variabili d'ambiente (cambiandole abbastanza per farle elaborare correttamente - Non sono sicuro di quanto sia abbastanza).

9
RobDavenport

l'ho chiesto ai forum Microsoft nel marzo 2009 e non l'ho mai risolto:

Come utilizzare% ProgramFiles% nella variabile di ambiente Path? :


Sto cercando di aggiungere una cartella alla variabile di ambiente Path del sistema.

voglio aggiungere % ProgramFiles%\SysInternals

alla variabile percorso esistente:

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

Quindi vado nel posto in cui lo modifichi:

alt text

E aggiungo la mia variabile al percorso:

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

Quindi, aprendo una nuova finestra Prompt del comando, la variabile d'ambiente non viene sostituita con il suo valore effettivo:

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

Che puoi vedere nello screenshot seguente:

alt text


Ma per rispondere alla tua domanda: non lo so. Sembra che non possa essere fatto.

7
Ian Boyd

ci sono due livelli di variabili di ambiente, globali e utente. Se ha% Java_home% impostato come variabile di ambiente utente ma sta invece cambiando quello globale, non vedrà alcuna differenza.

5
Sekhat

Aggiungere le variabili di ambiente mentre si è connessi alla sessione/console usando MSTSC.

Riavvia la macchina e troverai che le variabili di ambiente saranno persistenti.

Sembra che ci sia una stranezza nell'O/S a seconda di come eri connesso alla macchina quando tenti di cambiare la variabile d'ambiente.

2
Justin

Assicurarsi che non vi siano spazi nel PERCORSO quando si definiscono le proprie variabili di ambiente utente. ad es .: C:\GNAT\bin; C:\GNAT\include non funzionerà, a causa dello spazio tra ";" e "C:\GNAT\include".

2
Nij

Ho avuto lo stesso problema e so come risolverlo, è zoppo.

Modificare nuovamente PATH, ma non apportare modifiche e ri-salvare PATH. Per qualche ragione questo fa sì che tutti i riferimenti alle variabili d'ambiente annidati vengano rivalutati.

Se non funziona fallo altre volte, in qualche modo funziona da solo.

1
BAP

PATH è la concatenazione della variabile PATH dell'utente seguita dalla variabile PATH globale. Per usare una variabile all'interno di un'altra, la prima deve essere già impostata. Le variabili utente sono impostate prima delle variabili globali (almeno qui sul mio Windows 7 a 64 bit), quindi non è possibile utilizzare variabili globali nella variabile PATH dell'utente. Inoltre, le variabili sono impostate in ordine alfabetico, quindi è necessario tenerlo a mente.

1
cbarrick

Potrebbe essere correlato alla funzione "espansione variabile di ambiente ritardata" (o alla sua mancanza), o forse è possibile sfruttare questa funzionalità per avere sempre una soluzione corretta.

da un prompt cmd

set /? 

e leggi la sezione che descrive "espansione della variabile di ambiente ritardata", che include un piccolo esempio da testare

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

Se non ottieni la linea dell'eco, allora potrebbe spiegarlo ...

Se, tuttavia, si avvia il cmd.exe con l'opzione/V, è possibile utilizzare "!" invece di "%", che cambia il comportamento

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

Per me (in esecuzione su XP), il primo script non funzionava, ma la seconda versione (con cmd.exe/V)

1
libjack

Credo che Windows non riesca ad espandere una variabile in PATH perché pensa a ciò che non è ancora stato definito. Tenere conto:

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

Questa ipotesi è conforme alla mia altra osservazione: l'aggiunta di %ProgramFiles%\Something agli utenti PATH determinerà sempre l'espansione prevista di %ProgramFiles%, dato che è stata definita nell'ambiente macchina a il momento della notifica della variazione variabile (ordine di caricamento dovuto - MACCHINA e quindi UTENTE). Ma quando si modifica l'ambiente della macchina, l'espansione della variabile corretta avviene solo all'avvio (in questo momento non ho idea come e perché questo non accade su base regolare).

1
user539484

Ho risolto l'impostazione delle variabili di ambiente in Sistema> Impostazioni avanzate> Variabili d'ambiente .

Ci sono due pannelli, User e variabili globali (utente è il tuo nome utente Windows) e System Variables sono variabili globali, quindi se imposti "Nuovo" dalle variabili User, come Java_HOME e metti il ​​tuo percorso di seguito, imposterai le variabili anche se il tuo globale percorso ha file di programma all'interno della cartella.

0
thunder_nemesis

Forse stai sbagliando?

Ho provato con Windows XP Pro SP3 (32 bit). Ho un percorso con diverse occorrenze di %Java_HOME% (e %JAVAFX_HOME%, ecc.). Vado alla riga di comando, digitare PATH, vedo le variabili espanse. Buono.

Cambio il valore di Java_HOME. Torna alla stessa finestra della riga di comando, PATH di nuovo, lo stesso valore ... come previsto (per esperienza!).

Apro una nuova finestra della riga di comando, digito PATH, gotcha, vedo il nuovo valore.

Non sono sicuro di quale sia il meccanismo esatto, ma sembra che qualsiasi programma in esecuzione, incluso cmd.exe, acquisisca i valori delle variabili d'ambiente all'orario di inizio e non guardi indietro ... (anche se credo che un programma ben fatto possa ascolta i cambiamenti di env, non troppo sicuro però).

Potrebbe essere visto come una caratteristica o un bug o fastidio, ma è così che funziona. Ehi, almeno, a differenza delle volte Win9X, non dobbiamo riavviare il computer! E a differenza dei tempi NT (IIRC), non è necessario disconnettersi e tornare indietro.

Perché l'incoerenza? Le vie di Microsoft sono imperscrutabili ... :-P

0
PhiLho