I have some sort of a problem with the PATH system variable. Since I use a lot of cmd apps and scripts I've added a lot to it. But the string's length is not the issue. I've worked around this limitation.
Advanced System Properties is the only application which I've noticed to initialize the PATH variable properly after an edit. If I edit registry manually, apps don't use the updated version of the PATH. So I have to use it or keep loggin on and off.
However, lately, after setting some values of PATH in that app, it always ends up being (null), even if it's the same string. Once I press OK, it goes dark. Registry entries are still there. I have to log-off or restart for the PATH to get populated with whatever is in its registry entry.
I've even trimmed it down to %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem Still, PATH=(null) and %windir% is dead.
Leave it alone, it works.
Edit it, nope. Not until I restart.
So, any ideas?... about why advanced system properties is behaving like this when updating the system variables. I believe this is the issue, since it's an initializing app and since on a clean restart everything works.
After some tries, I managed to come up with some basic Environment variable rules when working with command line tools and PATH.
1st. A) Length: No Variable should be longer than 2047. If there are variables longer than 2047, variables after them won't expand, won't show up and Path will become null, PATH=(null).
It's very unlikely to arrive here but as it happens, I was in this situation and this was the main issue, however, this limitation is tricky, because it comes in effect only after editing the Environment variables in the editor (Advanced System Settings / SystemPropertiesAdvanced.exe). It will not have any negative effect if the variables are left unedited after booting up, but, if child explorer are executed for browsing in separate process, the command consoles opened from those explorer windows will be affected.
1st. B) Which Length? It doesn't matter. If a variable is used in Command console it is limited either way to 2047 chars of value, expanded or declared.
Declared:
ex:
x = %variable001%;%variable002%;%variable003%;...;%variable146%;%variable147%
Won't work.
Up to 146, it will because x won't be longer than 2047.
But 147 will kill it. Length of %variable???%; x 147 = 2058.
Expanded:
ex:
x001 = C:\Program Files
x002 = C:\Program Files
x003 = C:\Program Files
...
x120 = C:\Program Files
x121 = C:\Program Files
z = %x001%;%x002%;%x003%;...;%x120%;%x121%;
Will work but will show only up to x120 and part of x121.
Length of C:\Program Files; x 120 = 2040 + C:\Prog of x121
2nd. Place: Expandable variables don't expand recursively. In registry they are of type REG_EXPAND_SZ, in Environment variables editor they are set if the % character is typed in. If there are such variables declared, this needs to be done so that they are initialized before PATH. Normal variables don't have this issue. They can be declared after PATH and their values will still show.
ex:
a = C:\Windows
b (exp) = %SystemRoot%
c (exp) = %a%;%b%;%x%;%y%
x = C:\Windows
y (exp) = %SystemRoot%
z (exp) = %a%;%b%;%x%;%y%
echo %c% will output C:\Windows;C:\Windows;C:\Windows;%y%
a b x y
echo %y% will output C:\Windows
echo %z% will output C:\Windows;C:\Windows;C:\Windows;C:\Windows
a b x y
Variable y was not expanded inside c because it was declared after c, but was expanded in c's clone, z.
So, to keep PATH alive and well, there has to be no lengthy variable before it and it can contain expandable variables as long as they are declared before Path in an alphabetical hierarchy (from a to o). All while keeping a final value length below 2048.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다