Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Logged In: YES
We've had at least 3 reports of this now. After the second report I went and searched the NSIS bug tracker and their mailing lists and found no report by anyone of NSIS wiping out the PATH setting. Thinking that this had to be a NSIS problem and if so, someone would have reported it. Since it didn't seem as though it had ever been reported, I sort of dismissed this in my mind.
However, after this report, I went and took a closer look at what we are doing, guess I should have done that sooner. <grin>
I see a potential problem in the installer script we are using. For one thing, it looks like we are using a custom script for the path manipulation. That negates my logic that since no NSIS users had ever reported the problem, it was probably not an installer problem.
We have this logic in newpath.nsh:
Read the current path from the registry into $1
ReadRegStr $1 HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment" "$R8"
At this point we have the ooRexx directory location in $0 and the current PATH setting in $1 I put some print outs in the install log to verify that (I am installing to D:\Interpreters\Rexx\ooRexx):
$0 value: D:\Interpreters\Rexx\ooRexx
$1 value: E:\fasstWork\fasst\bin;E:\work.ooRexx\ooRexxUnit\3.x\framework; ...
Then we see if $1 is blank, and if it is! we go ahead and set the PATH to $0. This will of course produce exactly the symptom that people have reported. The existing PATH is replaced with only the ooRexx directory.
StrCmp $1 "" AddToPath_NTdoIt ; if current value is blank, do not prepend existing value
StrCpy $0 "$1;$0"
StrCmp $R7 "true" AddToPath_AllUsers_doit
; writing registry for current user
WriteRegExpandStr HKCU "Environment" "$R8" $0
DetailPrint "$4 added to $R8 for Current User"
; writing registry for all users
WriteRegExpandStr HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment" "$R8" $0
So, we have this: $1 should contain the current PATH setting. It will only be blank if some error ocurred. Apparently, when working with computers, some errors can occur. Who would have thought. <grin>
At this point, I don't see how we can recover, so we should not write a setting to the registry. The best solution is probably to put up a message box and tell the user sorry, the ooRexx directory was not added to the path, do it manually. Or some variation on that.
Although, it probably would not hurt to check after reading the PATH from the registry to see if it is blank, and if so, try to read it one more time. If it comes back blank twice then give up.
I'll implement a fix that prevents us from ever only writing the ooRexx directory to the PATH. I'm open to suggestions on what to present to the user:
1.) Message box saying sorry, add path manually, continue
2.) Message box saying sorry do you want to continue (and add the path manually) or abort the install entirely?
3.) Or ...
You seem to have CSS turned off.
Please don't fill out this field.
Committed revision 1859.
This code change detects if the value for current PATH or PATHEXT is the blank string. If so, it tries one more time to get the value and if not puts up a message box informing the user of an error and that the path will have to be updated manually.
We will never be certain that the logic error that existed in the installer actually caused this reported problem. But, since the logic of the installer would have produced exactly what has been described, it seems likely to me that this is fixed.
There is one other potential error in this area. Windows has, has always had, a limit on the maximum length of the path. Exactly what happens if you write a too long path to the registry seems non-deterministic.
To close out this bug, the installer should be fixed to check the length of the new path before writing it to the registry. If too long, inform the user and don't change the existing path.
Committed revision 4981.
In addition to Windows having a limit on the length of the path string in the registry, the NSIS installer has a limit of 1024 on the length of a string.
Added a check to determine what the string length would be when appending the ooRexx install directory to the current path. If the new string would be too long, the installer does not add the ooRexx to the path, and informs the user it needs to be done manually.
This is the last portential error that I see in connection with the PATH, so I'm closing this now.
Several changes in the Windows installer that were made prior to the 4.0.0 release should have eliminated any possibility of this bug. Since there have not been any other reports of anything similar, I'm switching this from pending to closed.