I have recently upgraded to Windows 10 from Windows 8.1.
Now I wanted to set an environment variable for my new installation of Apache Maven.
Each time I created the user variable, things were fine. However, I also need to create the system variable where I will need to append the bin directory to the variable that I already create in the user variable to be "path".
Now, each time I do this, I get an error that says "This environment variable is too large". As a result of this, I am unable to create the path.
I have attached an image of this error.
When the PATH environment variable gets overloaded with too many values it reaches a point where you cannot add values any more. Trying the following should solve your problem.
Solution 1:
Create a new system environment variable, say 'NEWPATH'
Assign the bin directory location to 'NEWPATH'
Now append '; %NEWPATH%' to the PATH environment variable
If this still doesn't work then try to copy some part of the PATH environment variable already existing values to the 'NEWPATH' and then append the 'NEWPATH'.
Solution 2:
Check the value of the PATH environment variable if you can group and shorten the paths. For example,
C:\Program Files\Microsoft SQL Server\102\Tools\Binn;C:\Program Files\Microsoft SQL Server\102\DTS\Bin;
can be combined to
C:\Program Files\Microsoft SQL Server;
In this way, you can build more space into your fixed length PATH variable and finally adjust your bin directory location into PATH.
There are a few ways to clean up your path variable. The easiest is to use Rapid Environment Editor. This free utility will,
Remove the duplicate paths (right click → Cleanup Paths)
Remove non-existent folders (shown in red which you need to manually delete)
Replace long paths with short paths (right click → long to short path).
I do the above steps in order and use the third step only for the longest paths until the Path variable size is under control again.
If you want to go more advanced, here's a little C# tool that you can modify to whatever other logic you want to implement.
Another solution, or more a workaround to bypass the PATH environment variable length limit, is to manage your path (add, remove or update) using a PowerShell script;
Capture the current PATH variable by clicking "Edit Text" (see above screenshot) and copy it to your clipboard and save it in a text file as a backup too to avoid bad surprises. This is not mandatory, but will allow you to recover should something go wrong.
Now that it is backed up, add the following to a new PowerShell (.ps1) file (amending the first line below with the folder path(s) you want to add (the part after the + sign):
$newPath = $env:Path + '; C:\Users\....\FirstFolderToAddToPath; C:\Users\....\SecondFolderToAddToPath;'
[Environment]::SetEnvironmentVariable("Path", $newPath, "Machine")
$env:Path = $newPath
This is how I managed to get my (long) PATH variable back after playing with the Windows 10 UI, being caught by the length limitation and losing most of my path.
Try to modify by RegEdit. In my case it works when length is more than 3000.
Press Win + R and enter regedit to open RegEdit. Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and modify the value of Path to your path. And restart the computer, and it should work.
In addition to the answer of Swapnil, note that you can modify the maximum length of the Path environment variable - which is otherwise limited to 2048 characters (while a single path has an historical limit of 206 characters).
In Windows 10, you achieve this by setting the LongPathsEnabled registry key to 1, which can be found here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
To access the registry editor: Windows key + R, type Regedit.
Source: Windows 10 “Enable NTFS long paths policy” option missing
Also take a look at this Super User answer: An answer to Windows 10 “Enable NTFS long paths policy” option missing
Note that the error "Environment variable is too large" is related to the whole variable, not the single path currently being added (to answer the "inaccurate advice" comment below).
Additional note: app compatibility
The text in the registry key/group policy related to LongPathsEnabled reads:
Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process.`
The caveat here is the term manifested. In general applications need to declare capabilities explicitly in a manifest file; most win32 applications since the days of Windows Vista are manifested. To use long paths, the app manifest needs a longPathAware element:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
More info here.
Some users complained that LongPathsEnabled is not yet supported by Windows Explorer and other apps, although in general working alternatives can be found. For example, in this forum post an user states that
The only explorer alternative that does support long paths and long file names is total commander. It also allows to edit file names and open/process the files IF the accepting application also uses the extended API function.
Notepad seems to. MKVtoolnix too. Also, very surprisingly, MPC-HC, even though it hasnt been in development for years. Not surprisingly, sucky VLC does not (seriously?) and neither does the lovely PotPlayer.
There is also an interesting SuperUser discussion on this. In particular, this answer describes two feasible alternatives to use long paths: using Cygwin (a *nix emulation layer) or splitting the long path using NTFS Junction Points (essentially a link, like a symbolic link).
I changed all the paths to variables for Program Files and programdata (this one saves like one character, though not as important).
For something like Node.js, I changed the normal path of
C:\Program Files\nodejs\
to
%ProgramFiles%\nodejs\
This can be done with "C:\Program Files (x86)" as well using "%ProgramFiles(x86)%".
It saved me a few characters, but enough that it stopped complaining, I feel.
I found you can do it via PowerShell.
[System.Environment]::SetEnvironmentVariable("PATH", "C:\Program Files (x86......etc.....", "Machine")
So I grabbed the existing system PATH, pasted into Notepad, added my new thing, and then pasted into the "C:\Program Files" bit of the above. Path was updated. Done.
Apparently Rapid Environment Editor will do this for you (from Shital Shah's answer), but you can also shorten the paths to their 8.3 filename version. You will get a lot of mileage with just these two replacements:
C:\Program Files --> C:\PROGRA~1
C:\Program Files (x86) --> C:\PROGRA~2
If you copy your current path into Notepad, first search and replace C:\Program Files (x86) and then C:\Program Files.
Workaround:
Please restart the system. After restarting the system, PATH is no longer empty, but it may get truncated to 2047 (4095) characters
If the system restart does not help, please:
Launch C:\windows\system32\regedit.exe. Go to the registry hive "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" and clean up unnecessary directories from the “Path” key. Restart the system.
Note: In some exceptional cases if the system is not able to start, please:
Login in the safe mode
Open the command prompt shell and type:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d ^%SystemRoot^%\system32;^%SystemRoot^% /f
For more details:
Limitation to the length of the System PATH variable
In addition to other methods (e.g., PowerShell), I found a nice GUI, "Rapid Environment Editor" that can handle larger text values.
You can also try going through your variables to see if there are any irrelevant paths you could delete. This would free up some space for you to add another or more variables.
So I figured out the same problem I had, I noticed there were many duplicates pointing to the same location.
I removed the duplicates which can be done with the delete option when you go click the "edit Environment Varibles" button.
You could instead edit text, copy the text from there, remove duplicates using any popular apps like notepad, excel (use the delimiter as ; then remove duplicates), or use python (use .split(";"), convert into a set, ";".join(stringSet), copy into a notepad file, then replace \ with \ using the ctrl+ H ie find and replace).
I had exactly the same problem. Eventually I had to delete one of the existing variables to make the total length less than 2047.
Then I could add %MAVEN_HOME%\bin to the path variables.
Workaround: Use the Edit text button and edit your PATH in a text editor.
I found this AutoHotkey script useful, for editing or adding to my extremely long path (3743 chars now):
https://gist.github.com/roblogic/59898966f3ce594eb78a5b6147013194
(I'm not sure what the consequence of such a long path is; I may still have to fix it.)
Related
In my experience, #f::Run mailmaster will launch mailmaster.exe when pressing #f, but throws when doing #f::Run QQMusic:
I had to provide the full path for QQMusic.exe whereas I didn't have to provide the full path for mailmaster.exe.
According to the documentation:
Run can launch Windows system programs from any directory. Note that executable file extensions such as .exe can be omitted.
Run notepad
Since both mailmaster.exe and QQMusic.exe are non-system programs and they are not included in the Path environment variable, why AutoHotkey is giving different behaviors for them?
And performance-wise, providing the full path versus just the .exe name, which is faster?
It's specified in the documentation:
Target
A document, URL, executable file (.exe, .com, .bat, etc.), shortcut (.lnk), or system verb to launch (see remarks). If Target is a local file and no path was specified with it, A_WorkingDir will be searched first. If no matching file is found there, the system will search for and launch the file if it is integrated ("known"), e.g. by being contained in one of the PATH folders.
So pretty much if it's found in PATH.
You can try this for example by typing notepad, mailmaster and QQMusic in cmd or powershell. Notepad is found in PATH, and on your system I'm assuming mailmaster is as well, and QQMusic isn't.
You should get the same results as with the AHK Run command.
As for performance, I don't know, I guess this is something you could benchmark.
I'd guess that providing the full path is more efficient.
But maybe finding something from PATH is very well optimized on the the Windows side of things, so maybe there is little to no difference.
I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).
Folks,
When I get a new PC, I always first partition my disk into C, D and E - then install Windows on C, other software on D, and use E for my own work. To make my installs easier, I first change the registry location of ProgramFilesDir (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir) to "D:\Program Files". Once I do this, all new installations go to D:\Program Files. Life was good.
Now I have Windows 7. I see that the Registry includes all these entries now...
CommonFilesDir
CommonFilesDir (x86)
CommonW6432Dir
ProgramFilesDir
ProgramFilesDir (x86)
By the time Windows 7 was installed, the two "CommonFiles" directories already had stuff installed. I decided to leave these untouched. The rest I changed to their D-drive equivalents.
So two issues...
First, new software installs STILL want to go to C:\Program Files. I always have to change the "C" to a "D" - which I've never had to do before. (Yes, I've rebooted plenty since making the registry change.)
Second, I'm finding that Visual Studio 2010 seems especially confused by this. I have installed .NET 4.0, and even tried repairing it, but VS 2010 insists I don't have 4.0 installed. (I've heard that others have this trouble, too, and VS 2010 seems to really want to be on the C-drive.)
Any help, dear friends, with either issue?
I suggest you do not change the reg to point to new drive for program files. Microsoft hard code many things to expect c:\program files and without this set=up all hell breaks loose. This especially true for updates etc.
See http://support.microsoft.com/kb/933700
MS does not support changing location of program files!
The reality is we just have to expicitly set "d" every time we go to install something!
Here is what I came up with, I haven't tried it as I have not ordered my SSD, but everyone
should try this. Two easy Parts, Just a few steps each.
Part 1
A)
Start > Control Panel > System > Advanced System Options(Win XP?/Vista/7/8)
Pop-Up window > Go to: Advanced Tab, at Top > Environment Variables, at bottom right.
Bottom window area Marked: System Path > New Button
Variable Name: CSIDL_PROGRAM_FILES
Variable Value: X:\Program Files\
Replacing X with your drive letter, and remembering to use \ back slash, not forward slash /
This is the end if you have a simple 32-Bit(x86 platformed) PC.
For part B, This is where we 64-Bit platformed PC-goers have to do this additional step.
for x64 the variable acts as the standard still program structure, but WoW64 compliant via registry separator.
So what we have to do is just an additional variable, with a slight change of the Name for each new values.
B)
Bottom window area Marked: System Path > New Button
Variable Name: CSIDL_PROGRAM_FILESX86
Variable Value: X:\Program Files (x86)\
This sets our 32-Bit Platformed programs which still exist in our new environment,
as most programs do not need to use to this day more threads, and they are built that way.
Part 2
The standard changing your registry keys for default program files installs.
Start > Run > enter "regedit" Hit Enter.
Navigate on left tree to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
change two values that appear on right frame, as we did before. Only one is needed for x86 Platform,
If you do not own 64-bit, You need not change the second value.
A)
Variable Name: ProgramFilesDir
Variable Value: X:\Program Files
B) (If you have 64-Bit windows)
Variable Name: ProgramFilesDir (x86)
Variable Value: X:\Program Files (x86)
Side note, Notice this variable set does not have an additional backwards "\"
on it, as it can't have in it in this particular section, I do not know why as of yet ahahahah,
but I would just follow prior formatting of how it was.
How about using GimmiLFactorY suggestion and then adding a hard link to the program folders, or rather, use a directory junction. The following article shows how you can do this easily:
http://ipggi.wordpress.com/2009/09/07/windows-file-junctions-symbolic-links-and-hard-links/
The 64bit version has two versions of regedit. Make this change as well:
1.) Enter into Start >Run: %systemroot%\syswow64\regedit
2.) Go to: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion
3.) Change the Path in DWORDs ProgramFilesDir, ProgramFilesDir (x86) to the new path, probably just changing the drive letter.
In many of my Access (2002) programs I use the GetOpenFileNameA and GetSaveFileNameA functions from comdlg32.dll. I often set the initial directory to the user's My Documents folder (using calls to SHGetSpecialFolderLocation and SHGetPathFromIDListA from shell32). This all works fine under Windows XP.
However, I recently switched to Windows 7 as my development environment and have been getting the following error message:
You can’t open this location using
this program. Please try a different
location.
The function I use to get the My Documents location is returning the correct folder. However, even if I hard code that directory location into the GetOpenFileNameA call, I still get the error.
I came across this post: http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d but, even adapting it to work with Access instead of Excel, I had no luck.
EDIT: Suddenly this is no longer a problem for me. I suspect a windows update went out addressing this issue. Does anyone know if that's true or not?
EDIT: It turns out this is still a problem. Also, in case it helps in the troubleshooting I have found that I get this error message for any of the special folder locations (My Music, My Documents, etc). Also, if I change the location of the My Music folder to, say, C:\Test then I get this message when I try to open the folder C:\Test, while the folder C:\Users\Mike\Music (the original My Music location) opens without a hitch.
Windows 7 adds the concept of a "library", which is basically a virtual folder that includes the contents of at least two actual subdirectories. One place it uses the library is the "My Documents" folder, which (at least by default) is a library that includes both the user's documents directory ("c:\users\whoever\documents") and the public documents directory (C:\users\public\documents").
As such, the basic approach you're using simply can't work -- there is no path that denotes the Documents folder. The documents folder needs to be specified by a PIDL, not a path.
Edit: It's not clear what's going on if you can't open C:\users\user\Documents. A quick test in C++ works fine using code like:
OPENFILENAME data = {0};
wchar_t filename[256] = {0};
data.lpstrInitialDir = L"C:\\users\\jerry\\documents";
data.lStructSize = sizeof(data);
data.lpstrFile = filename;
data.nMaxFile = sizeof(filename);
GetOpenFileName(&data);
OTOH, there's no real need to specify the initial path -- the Documents folder is the default anyway.
The link I posted in my original question (http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d) held the answer after all. I'll summarize things here. To fix this behavior, you need to do away with the STRIPFOLDERBIT flag in the shell compatibility registry entry for all affected programs.
Keep in mind (and this is what tripped me up for so long) that 32-bit programs have entries in a special registry section if you have 64-bit windows. Here's the quick and dirty:
Rename STRIPFOLDERBIT to xSTRIPFOLDERBIT for the following keys (as applicable):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe