Increase length of system Path environment variable?
nospam
confirm or deny this?
"On NT and Win2K, environment variables can't be longer than 1023
characters, even with environment variable expansion, even with COMSPEC =
%SystemRoot%\system32\cmd.exe /e:32768"
Is there any other way to increase the system PATH size? We are stuck with
using dozens of applications that require things appended to the path in
order to run properly, and we are about to reach the limit (we didn't write
them but we're stuck with using them.)
2. Details:
Through experimentation, we determined that the maximum size of any
environment variable on Windows NT 4.0 and Windows 2000 is 1023 characters.
The Windows user interface for modifying environment variables limits data
entry to 1023. You can go directly into the registry
(HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session
Manager\Environment) and put in something bigger than that (I put in 5K of
data), but from a DOS prompt it still truncates at 1023. If you try
running it from the "Start|Run" window it still will only use a search path
limited to 1023 characters. The behavior is exactly the same no matter what
the environment size is in COMSPEC (tried the default, then 2048, and then
the max, 32768)
For environment variables that contain other environment variables, the
limit is still 1023 even after expansion, so everything else is truncated
after the 1023 char limit.
I re-read the knowledgebase article, Q158141, "How to Specify Additional
Environment Space under Windows NT," and realized it just talks about
environment space, not enviroment variable length. (Correct me if I'm
wrong, but "environment space" should be the sum of all environment
variables, maybe some other overhead I'm not aware of.) I was originally
mislead/confused because I saw about a dozen different newsgroup replies,
FAQs, and articles from various sources that referenced this article and
recommended changing COMPSPEC to fix problems with the Path length.
Evidentally this was bad advice, at least for Windows NT 4.0 and Win2K.
A lot of the articles recommended setting the evironment space to 2048, but
we did a quick count of all the environment variables on a DOS prompt on one
of our "bricks" (images/bundled systems) and we've exceed 2048 characters.
I think what happened is this article was updated for Windows 2000 but they
forgot to mention what the default environment space (not path length) is,
and they also kept the example at 2048 because earlier versions of the
article used that number in their examples.
Following references support the behavior I experienced (path limited to
1023 characters):
1. http://www.jsiinc.com/SUBD/tip1900/rh1907.htm
2. MSDN KnowledgeBase Article Q169888, "User-Define Path Dropped When User
and System Paths Too Large"
(The bug itself is supposed to be fixed in a service pack, but the "More
Information" section in this article still seems to hold true.)
The maximum length of the combined system and user-defined path variables is
1,023 characters. This does not includes the "path=" portion of either.
The system path is limited to the maximum path length of 1,023 characters.
The user-defined path is limited to maximum 511 characters, but is limited
to 1,023 minus the system path.
It is possible that the system path can use the total allocated environment
space, causing the user-defined path to get truncated or not show up at all.
-----Original Message-----
From: <deleted>
Sent: <deleted>
To: <deleted>
Subject: MSDN KB Q158141, "How to Specify Additional Environment Space under
Windows NT" was RE: Windows Search Path
Finally found it... MSDN Knowledge Base Article Q158141, "How to Specify
Additional Environment Space under Windows NT"
In Windows 2000:
1. In Control Panel, double-click System.
2. Click the Advanced tab, click Environment Variables. In the System
variables, click ComSpec.
3. To increase the amount of environment space, use the following syntax:
ComSpec = <drive:\windir>\system32\cmd.exe /e:2048
where <drive:\windir> is the drive and folder where the Windows 2000 system
files are located.
(My note: try to use ComSpec = %systemroot%\system32\cmd.exe /e:2048)
The maximum size for the /E: switch is 32768 bytes.
Same for NT, except you get to the environment dialog a slightly different
way.
-----Original Message-----
From: <deleted>
Sent: <deleted>
To: <deleted>
Cc: <deleted>
Subject: Windows Search Path
. . .
I frequently come across problems with my Windows search path when I load
new applications onto my system. It seems that both NT and W2K have problems
with search paths of more than 512 characters. Is someone working on
reducing the search path for on our systems and/or increasing the valid
maximum path length?
Phil Robyn
> Can someone (preferably from Microsoft, but I'll take anyone's input)
> confirm or deny this?
>
> "On NT and Win2K, environment variables can't be longer than 1023
> characters, even with environment variable expansion, even with COMSPEC =
> %SystemRoot%\system32\cmd.exe /e:32768"
>
> Is there any other way to increase the system PATH size? We are stuck with
> using dozens of applications that require things appended to the path in
> order to run properly, and we are about to reach the limit (we didn't write
> them but we're stuck with using them.)
Why do you need to increase the path size? Can't you simply start your
applications from batch files and set the path in each batch file to whatever
that application requires before the batch file invokes the application?
--
u n z i p m y a d d r e s s t o s e n d e - m a i l
shockwaveriderz-MVP
--
MS MVP 2002
NT4 MVP 1999-2000
"nospam" <nos...@nospam.com> wrote in message news:uDlTKhm4BHA.568@tkmsftngp05...
Simon Sheppard
<pro...@uclink.berkzipeley.edu> wrote:
>nospam wrote:
>
>> Can someone (preferably from Microsoft, but I'll take anyone's input)
>> confirm or deny this?
>>
>> "On NT and Win2K, environment variables can't be longer than 1023
>> characters,
>
>Why do you need to increase the path size? Can't you simply start your
>applications from batch files and set the path in each batch file to whatever
>that application requires before the batch file invokes the application?
>
>
Presumably these are Win32 apps that won't run in the same environment
space as a batch file calling the application.
Therefore, although (with the correct rights) you can use SETX to
change the system path on the fly, this would almost certainly cause
problems as soon as users start running multiple apps at the same time
- If every batch file replaces the whole path then only the last
application is going to work correctly - If every batch file appends
to the path then you will run into the limit (and will need some
mechanism to remove duplicates from the path)
Although it's not pretty, the easiest workaround is to use SUBST to
map the long paths to drive letters, so C:\program files\my app
becomes T:\
Another option that may be worth trying under Win 2K is to use RUNAS
having a different user account (with different user path) for each
app.
So the application's PATH is under:
HKCU\Environment
General PATH under:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Lastly it's worth experimenting with shortcut properties, some
applications will run quite happily if the directory is simply set
under the shortcut property START IN:
-
Simon Sheppard
Web: http://www.ss64.com
email: Simon@ "
-
Torgeir Bakken
> Can someone (preferably from Microsoft, but I'll take anyone's input)
> confirm or deny this?
>
> "On NT and Win2K, environment variables can't be longer than 1023
> characters, even with environment variable expansion, even with COMSPEC =
> %SystemRoot%\system32\cmd.exe /e:32768"
>
> Is there any other way to increase the system PATH size? We are stuck with
> using dozens of applications that require things appended to the path in
> order to run properly, and we are about to reach the limit (we didn't write
> them but we're stuck with using them.)
You can create a VBScript for each program and let the user launch them instead:
' This script will add a folder to the existing path and start a program.
' It will only apply to the current session ("Process" a.k.a the running
VBScript) and
' it's subsequent child processes.
' Path to add
sAddOn = "c:\test\newpath"
Set WshShell = CreateObject("WScript.Shell")
Set WshProcessEnv = WshShell.Environment("Process")
sCurrPath = WshProcessEnv("PATH")
If Right(sCurrPath, 1) = ";" Then
sNewPath = sCurrPath & sAddOn
Else
sNewPath = sCurrPath & ";" & sAddOn
End If
' Set the environment variable
WshProcessEnv("PATH") = sNewPath
' Start the program that is placed in sAddOn
WshShell.Run "newprog.exe"
--
torgeir
nospam
Problem is that we have a huge system (about 50 different pieces) with lots
of legacy applications and Unix ports, especially government crap.
"Phil Robyn" <pro...@uclink.berkzipeley.edu> wrote in message
news:3CB770DD...@uclink.berkzipeley.edu...
nospam
"shockwaveriderz-MVP" <shockwa...@hotmail.com> wrote in message
news:#h1HN8w4BHA.1456@tkmsftngp02...
nospam
already using the local PATH in scripts and batch files (similar to your
example below) as much as possible and are still hitting the limit. Problem
is that we have a huge system (about 50-60 different pieces of software)
with lots of legacy applications and Unix ports, especially government crap.
workaround isn't an option. Just wanted verification that there is no way
to increase the character limit for environment variables.
Once I have documentation backing this up (the newsgoup replies do help) I
have to approach the contractors and government people and file complaints,
etc. A lot of this software is written by people who are just porting
things from Unix to Windows, and they don't care how they write their code.
We've exhausted the scripting and batch file workarounds suggested
already...
"Torgeir Bakken" <Torgeir.B...@hydro.com> wrote in message
news:3CBA1725...@hydro.com...
Alex K. Angelopoulos
you can apply are limited to controlling the path length by some means; you
won't be able to increase it.
(1) Use Phil's technique as much as possible.
(2) If you can, make individual path elements short by using very short
folder/sharenames and directly sharing the root of individual folders you use.
(3) Use the SUBST command to extend the reach of individual path elements.
"nospam" <nos...@nospam.com> wrote in message
news:ecRLroV5BHA.1852@tkmsftngp07...
Jonathan de Boyne Pollard
n> confirm or deny this?
<URL:http://groups.google.com/groups?selm=3BCD43BA.3C0FA2B6%40tesco.net>
n> Is there any other way to increase the system PATH size?
The limit you are experiencing is _not_ the limit on the length of the
environment variable. Environment variables can be a lot longer than
1023 characters. The limit that you are experiencing is the limit on
the length of command lines, which indirectly affects the lengths of
environment variables only inasmuch as it restricts how long the command
tail passed to a SET command can be.
<URL:http://groups.google.com/groups?selm=3BC84045.F2189625%40tesco.net>
n> [...] from a DOS prompt [...]
n> [...] all the environment variables on a DOS prompt [...]
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/a-cli-is-not-a-dos-prompt.html>
marge dahl
Can chop it up?
marge dahl
set the path to some huge string. It wouldn't work. I also
attempted to set this environmental to something huge thru the
control panel, system, env tab. It choked too. I have this
feeling there is a real limit to the path env. But I don't
have any inside info. Clay? You there?
Love Marge.
Just tried to set ANY env to a long string. Doesn't work. There
does seem to be a limit. But I'm not sure. Will be interested to see
how to do it.
NT 4sp6
Jonathan de Boyne Pollard <J.deBoyn...@tesco.net> wrote in message news:<3CDEBB22...@tesco.net>...
Clay Calvert
wrote:
>I wrote a program in an alternative script that attempted to
>set the path to some huge string. It wouldn't work. I also
>attempted to set this environmental to something huge thru the
>control panel, system, env tab. It choked too. I have this
>feeling there is a real limit to the path env. But I don't
>have any inside info. Clay? You there?
>
>Love Marge.
>
>Just tried to set ANY env to a long string. Doesn't work. There
>does seem to be a limit. But I'm not sure. Will be interested to see
>how to do it.
I could only set an environment variable to about 2040 characters in
Win2K using the command line. I the Sytems tab, the limitation was
only 155 characters, for some odd reason.
Clay Calvert
Replace "W" with "L" in email.
marge dahl
cut of what's going on here. Why do you need a path so long? Not
saying you don't, just would like to see the application. Thanks.
"nospam" <nos...@nospam.com> wrote in message news:<ecRLroV5BHA.1852@tkmsftngp07>...
Alex K. Angelopoulos
The line length, you are only 99.7% right about... it's apparently 2046
characters.
If you ever try to drag and drop a lot of files onto a script in the shell,
you'll see the same limit crop up - it dies a2046 characters...
"Clay Calvert" <ccal...@Wanguru.com> wrote in message
news:8ru0euokcb4vkii1s...@4ax.com...
Alex K. Angelopoulos (MVP)
was dealing with a bunch of custom apps written by contracting firms that all
wanted to add their things to paths. It was working OK until they go to the
point where a lot of integration of different tools on the same workstations
began, and then they ran into path limitations.
"marge dahl" <marda...@yahoo.com> wrote in message
news:92bd2c30.02051...@posting.google.com...
Clay Calvert
<waterco...@netscape.net> wrote:
>I am betting the system tab issue is a limitation in registry string value size.
>
>The line length, you are only 99.7% right about... it's apparently 2046
>characters.
Right. I said "set an environment variable" in the command line.
Subtract "SET X=" from 2046 and you get 2040. : )
Alex K. Angelopoulos
"Clay Calvert" <ccal...@Wanguru.com> wrote in message
news:uh83eu0ge2s4s75n8...@4ax.com...
Clay Calvert
<waterco...@netscape.net> wrote:
>I stand corrected... Or does that make me 100.3% correct.. ?
LOL! Yep, you're 100.3% correct!!!
Al Dunbar
"Clay Calvert" <ccal...@Wanguru.com> wrote in message
> On Tue, 14 May 2002 20:18:57 -0500, "Alex K. Angelopoulos"
> <waterco...@netscape.net> wrote:
>
> >I stand corrected... Or does that make me 100.3% correct.. ?
>
> LOL! Yep, you're 100.3% correct!!!
No! He is still only 99.7% correct, but he SITS corrected!
/Al
PS: it's late, must go to sleep soon.
Jonathan de Boyne Pollard
AKA> I am betting the system tab issue is a limitation in registry
AKA> string value size.
My educated guess is that the entry field in which one enters the value
has a length limit.
AKA> The line length, you are only 99.7% right about... it's
AKA> apparently 2046 characters.
He's roughly 30% right about it, because he didn't read the link that I
posted in my previous message, and so didn't realise that it varies from
command interpreter to command interpreter.
<URL:http://groups.google.com/groups?selm=3BCD43BA.3C0FA2B6%40tesco.net>