www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd installer clobbers PATH on Windows (sometimes)

reply Brad Anderson <eco gnuk.net> writes:
The NSIS script used to update the environment variable (EnvVarUpdate) has
the following warning [1]:

"Warning this code will replace paths rather than append if the existing
path exceeds the maximum string length in the NSIS build you are using. Some
setup crash can also occurs."

The default maximum string length is 1024.  There is a special build of NSIS
[2] which has a larger maximum string length (8192) that would help avoid
this problem.  There is also a patch [1] for EnvVarUpdate that detects if
the PATH will be overwritten instead of appended to and tells the user to
update their PATH manually.

I've seen this issue complained about before online but
hadn't experienced it myself until recently.  It can be a rather frustrating
problem to experience as restoring your PATH isn't trivial because there is
no way (that I know of) to look at what your PATH was before it was
destroyed and the PATH is often updated by installers (as it is with dmd).

[1]
http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning
[2] http://nsis.sourceforge.net/Special_Builds

Regards,
Brad Anderson
Aug 01 2011
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 8/1/11 2:58 PM, Brad Anderson wrote:

 The NSIS script used to update the environment
 variable (EnvVarUpdate) has the following warning [1]:

 "Warning this code will replace paths rather than append if the existing
 path exceeds the maximum string length in the NSIS build you are using.
 Some setup crash can also occurs."

 The default maximum string length is 1024.  There is a special build of
 NSIS [2] which has a larger maximum string length (8192) that would help
 avoid this problem.  There is also a patch [1] for EnvVarUpdate that
 detects if the PATH will be overwritten instead of appended to and tells
 the user to update their PATH manually.

 I've seen this issue complained about before online but
 hadn't experienced it myself until recently.  It can be a rather
 frustrating problem to experience as restoring your PATH isn't trivial
 because there is no way (that I know of) to look at what your PATH was
 before it was destroyed and the PATH is often updated by installers (as
 it is with dmd).

 [1]
 http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning
 [2] http://nsis.sourceforge.net/Special_Builds

 Regards,
 Brad Anderson


Hi Brad,

IIRC I wrote the installer and I knew about the problem too because some 
people started complaining about it but I didn't know of the solution 
(maybe at that moment the solution was not known). So good you found it :-)

What we can do is to copy this patched EnvVarUpdate function to the 
installer script and use it, I think it'll be much more safe than to 
just hope the system that runs the nsis script has the patched function 
or the special build.

What do you think? Could you make that change and do a pull request? (I 
don't have a Windows machine near me anymore nor a VM).
Aug 01 2011
next sibling parent Brad Anderson <eco gnuk.net> writes:
I can make a pull request. I do think we should do what we can to have the
person that rolls the release (Walter?) use the special build though. That
way nearly everyone can benefit from the convenient PATH update in the
installer.  We programmers tend to have very large PATH variables and it'd
be unfortunate if many D users received an error message whenever they
installed and were forced to update their PATH manually (although that's
clearly an improvement over the current situation).

On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana <ary esperanto.org.ar> wrote:


 On 8/1/11 2:58 PM, Brad Anderson wrote:


 The NSIS script used to update the environment
 variable (EnvVarUpdate) has the following warning [1]:

 "Warning this code will replace paths rather than append if the existing
 path exceeds the maximum string length in the NSIS build you are using.
 Some setup crash can also occurs."

 The default maximum string length is 1024.  There is a special build of
 NSIS [2] which has a larger maximum string length (8192) that would help
 avoid this problem.  There is also a patch [1] for EnvVarUpdate that
 detects if the PATH will be overwritten instead of appended to and tells
 the user to update their PATH manually.

 I've seen this issue complained about before online but
 hadn't experienced it myself until recently.  It can be a rather
 frustrating problem to experience as restoring your PATH isn't trivial
 because there is no way (that I know of) to look at what your PATH was
 before it was destroyed and the PATH is often updated by installers (as
 it is with dmd).

 [1]
 http://nsis.sourceforge.net/**Environmental_Variables:_**
 append,_prepend,_and_remove_**entries#Warning<http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning>
 [2] http://nsis.sourceforge.net/**Special_Builds<http://nsis.sourceforge.net/Special_Builds>

 Regards,
 Brad Anderson


 Hi Brad,

 IIRC I wrote the installer and I knew about the problem too because some
 people started complaining about it but I didn't know of the solution (maybe
 at that moment the solution was not known). So good you found it :-)

 What we can do is to copy this patched EnvVarUpdate function to the
 installer script and use it, I think it'll be much more safe than to just
 hope the system that runs the nsis script has the patched function or the
 special build.

 What do you think? Could you make that change and do a pull request? (I
 don't have a Windows machine near me anymore nor a VM).
Aug 01 2011
prev sibling parent Brad Anderson <eco gnuk.net> writes:
On Mon, Aug 1, 2011 at 12:54 PM, Brad Anderson <eco gnuk.net> wrote:


 I can make a pull request. I do think we should do what we can to have the
 person that rolls the release (Walter?) use the special build though. That
 way nearly everyone can benefit from the convenient PATH update in the
 installer.  We programmers tend to have very large PATH variables and it'd
 be unfortunate if many D users received an error message whenever they
 installed and were forced to update their PATH manually (although that's
 clearly an improvement over the current situation).


Pull request made.  I have not tested it as I'm not familiar with the dmd
build process and don't have time at the moment to figure it out. I can test
some other day if necessary.





 On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana <ary esperanto.org.ar> wrote:


 On 8/1/11 2:58 PM, Brad Anderson wrote:


 The NSIS script used to update the environment
 variable (EnvVarUpdate) has the following warning [1]:

 "Warning this code will replace paths rather than append if the existing
 path exceeds the maximum string length in the NSIS build you are using.
 Some setup crash can also occurs."

 The default maximum string length is 1024.  There is a special build of
 NSIS [2] which has a larger maximum string length (8192) that would help
 avoid this problem.  There is also a patch [1] for EnvVarUpdate that
 detects if the PATH will be overwritten instead of appended to and tells
 the user to update their PATH manually.

 I've seen this issue complained about before online but
 hadn't experienced it myself until recently.  It can be a rather
 frustrating problem to experience as restoring your PATH isn't trivial
 because there is no way (that I know of) to look at what your PATH was
 before it was destroyed and the PATH is often updated by installers (as
 it is with dmd).

 [1]
 http://nsis.sourceforge.net/**Environmental_Variables:_**
 append,_prepend,_and_remove_**entries#Warning<http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning>
 [2] http://nsis.sourceforge.net/**Special_Builds<http://nsis.sourceforge.net/Special_Builds>

 Regards,
 Brad Anderson


 Hi Brad,

 IIRC I wrote the installer and I knew about the problem too because some
 people started complaining about it but I didn't know of the solution (maybe
 at that moment the solution was not known). So good you found it :-)

 What we can do is to copy this patched EnvVarUpdate function to the
 installer script and use it, I think it'll be much more safe than to just
 hope the system that runs the nsis script has the patched function or the
 special build.

 What do you think? Could you make that change and do a pull request? (I
 don't have a Windows machine near me anymore nor a VM).







 Aug 01 2011



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Mon, 01 Aug 2011 20:58:08 +0300, Brad Anderson <eco gnuk.net> wrote:


 there is no way (that I know of) to look at what your PATH was before it  
 was destroyed and the PATH is often updated by installers (as it is with  
 dmd).


If you haven't rebooted your machine yet - Windows stores a backup copy of  
the system registry hives for the "last known good configuration" boot  
feature. These copies are stored in C:\Windows\Repair (XP and before) or  
C:\Windows\System32\config\RegBack (Vista and after). You will not be able  
to access these files directly, though - you'll need to use a tool or risk  
a poweroff and boot from another OS. Once you have a readable copy, you  
can "mount" the hives to an empty key in your registry with RegEdit. PATH  
is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session  
Manager\Environment (though you won't see CurrentControlSet in the mounted  
hive, it's a symbolic link of sorts to one of the ControlSetXXX keys).

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net



 Aug 01 2011



 next sibling parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Tue, 02 Aug 2011 03:35:23 +0300, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:


 and boot from another OS


Sorry, forgot to add: or simply select the "last known good configuration"  
start-up option, you should boot with the old registry. This will probably  
clobber all system registry changes since then, though.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net



 Aug 01 2011



prev sibling  parent  Brad Anderson <eco gnuk.net>  writes:


On Mon, Aug 1, 2011 at 6:35 PM, Vladimir Panteleev <
vladimir thecybershadow.net> wrote:


 On Mon, 01 Aug 2011 20:58:08 +0300, Brad Anderson <eco gnuk.net> wrote:

  there is no way (that I know of) to look at what your PATH was before it

 was destroyed and the PATH is often updated by installers (as it is with
 dmd).


 If you haven't rebooted your machine yet - Windows stores a backup copy of
 the system registry hives for the "last known good configuration" boot
 feature. These copies are stored in C:\Windows\Repair (XP and before) or
 C:\Windows\System32\config\**RegBack (Vista and after). You will not be
 able to access these files directly, though - you'll need to use a tool or
 risk a poweroff and boot from another OS. Once you have a readable copy, you
 can "mount" the hives to an empty key in your registry with RegEdit. PATH is
 located at HKEY_LOCAL_MACHINE\SYSTEM\**CurrentControlSet\Control\**Session
 Manager\Environment (though you won't see CurrentControlSet in the mounted
 hive, it's a symbolic link of sorts to one of the ControlSetXXX keys).


-- 

 Best regards,
  Vladimir                           
mailto:vladimir **thecybershadow.net<vladimir thecybershadow.net>


I'll try this.  Thanks for the tip.

Regards
Brad Anderson



 Aug 02 2011



prev sibling  parent  Johann MacDonagh <johann.macdonagh.no spam.gmail.com>  writes:


On 8/1/2011 1:58 PM, Brad Anderson wrote:

 The NSIS script used to update the environment
 variable (EnvVarUpdate) has the following warning [1]:

 "Warning this code will replace paths rather than append if the existing
 path exceeds the maximum string length in the NSIS build you are using.
 Some setup crash can also occurs."

 The default maximum string length is 1024.  There is a special build of
 NSIS [2] which has a larger maximum string length (8192) that would help
 avoid this problem.  There is also a patch [1] for EnvVarUpdate that
 detects if the PATH will be overwritten instead of appended to and tells
 the user to update their PATH manually.

 I've seen this issue complained about before online but
 hadn't experienced it myself until recently.  It can be a rather
 frustrating problem to experience as restoring your PATH isn't trivial
 because there is no way (that I know of) to look at what your PATH was
 before it was destroyed and the PATH is often updated by installers (as
 it is with dmd).

 [1]
 http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning
 [2] http://nsis.sourceforge.net/Special_Builds

 Regards,
 Brad Anderson


Thanks for looking this up. This *has* happened to me, and I've seen a 
few posts on reddit where this happened to someone else as well.



 Aug 02 2011