www.digitalmars.com         C & C++   DMDScript  

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

reply Brad Anderson <eco gnuk.net> writes:
--0015174beed4ad063104a9755f94
Content-Type: text/plain; charset=ISO-8859-1

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

--0015174beed4ad063104a9755f94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The NSIS script used to update the environment variable=A0(EnvVarUpdate)=A0=
has the following warning [1]:<div><br></div><div><div>&quot;Warning this c=
ode 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.&quot;</div>
</div><div><br></div><div>The default maximum string length is 1024. =A0The=
re is a special build of NSIS [2] which has a larger maximum string length =
(8192) that would help avoid this problem. =A0There is also a patch=A0[1]=
=A0for EnvVarUpdate that detects if the PATH will be overwritten instead of=
 appended to and tells the user to update their PATH manually.</div>
<div><br></div><div>I&#39;ve seen this issue complained about before online=
 but hadn&#39;t=A0experienced=A0it myself until recently. =A0It can be a ra=
ther frustrating problem to experience as restoring your PATH isn&#39;t tri=
vial 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).</div>
<div><br></div><div>[1]=A0<a href=3D"http://nsis.sourceforge.net/Environmen=
tal_Variables:_append,_prepend,_and_remove_entries#Warning">http://nsis.sou=
rceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#W=
arning</a></div>
<div>[2]=A0<a href=3D"http://nsis.sourceforge.net/Special_Builds">http://ns=
is.sourceforge.net/Special_Builds</a></div><div><br></div><div>Regards,</di=
v><div>Brad Anderson</div>

--0015174beed4ad063104a9755f94--
Aug 01 2011
next sibling parent 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
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--0015174760fcd1e5d504a9762aa6
Content-Type: text/plain; charset=ISO-8859-1

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).

--0015174760fcd1e5d504a9762aa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 inst= aller. =A0We programmers tend to have very large PATH variables and it&#39;= d be unfortunate if many D users=A0received=A0an error message whenever the= y installed and were forced to update their PATH manually (although that&#3= 9;s clearly an improvement over the current situation).<br> <br><div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana= <span dir=3D"ltr">&lt;<a href=3D"mailto:ary esperanto.org.ar">ary esperant= o.org.ar</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On 8/1/11 2:58 PM, Brad Anderson wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The NSIS script used to update the environment<br> variable (EnvVarUpdate) has the following warning [1]:<br> <br> &quot;Warning this code will replace paths rather than append if the existi= ng<br> path exceeds the maximum string length in the NSIS build you are using.<br> Some setup crash can also occurs.&quot;<br> <br> The default maximum string length is 1024. =A0There is a special build of<b= r> NSIS [2] which has a larger maximum string length (8192) that would help<br=

detects if the PATH will be overwritten instead of appended to and tells<br=

<br> I&#39;ve seen this issue complained about before online but<br> hadn&#39;t experienced it myself until recently. =A0It can be a rather<br> frustrating problem to experience as restoring your PATH isn&#39;t trivial<= br> because there is no way (that I know of) to look at what your PATH was<br> before it was destroyed and the PATH is often updated by installers (as<br> it is with dmd).<br> <br> [1]<br> <a href=3D"http://nsis.sourceforge.net/Environmental_Variables:_append,_pre= pend,_and_remove_entries#Warning" target=3D"_blank">http://nsis.sourceforge= .net/<u></u>Environmental_Variables:_<u></u>append,_prepend,_and_remove_<u>= </u>entries#Warning</a><br> [2] <a href=3D"http://nsis.sourceforge.net/Special_Builds" target=3D"_blank= ">http://nsis.sourceforge.net/<u></u>Special_Builds</a><br> <br> Regards,<br> Brad Anderson<br> </blockquote> <br></div></div> Hi Brad,<br> <br> IIRC I wrote the installer and I knew about the problem too because some pe= ople started complaining about it but I didn&#39;t know of the solution (ma= ybe at that moment the solution was not known). So good you found it :-)<br=

<br> What we can do is to copy this patched EnvVarUpdate function to the install= er script and use it, I think it&#39;ll be much more safe than to just hope= the system that runs the nsis script has the patched function or the speci= al build.<br> <br> What do you think? Could you make that change and do a pull request? (I don= &#39;t have a Windows machine near me anymore nor a VM).<br> </blockquote></div><br> --0015174760fcd1e5d504a9762aa6--
Aug 01 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--0015174beed469ba7e04a9766a9a
Content-Type: text/plain; charset=ISO-8859-1

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).


--0015174beed469ba7e04a9766a9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 12:54 PM, Brad An= derson <span dir=3D"ltr">&lt;<a href=3D"mailto:eco gnuk.net">eco gnuk.net</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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 inst= aller. =A0We programmers tend to have very large PATH variables and it&#39;= d be unfortunate if many D users=A0received=A0an error message whenever the= y installed and were forced to update their PATH manually (although that&#3= 9;s clearly an improvement over the current situation).<div> <div></div><div class=3D"h5"></div></div></blockquote><div><br></div><div>P= ull request made. =A0I have not tested it as I&#39;m not familiar with the = dmd build process and don&#39;t have time at the moment to figure it out. I= can test some other day if necessary.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"><div><div class=3D"h5">=A0</d= iv></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div class=3D"h5"> <br><div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana= <span dir=3D"ltr">&lt;<a href=3D"mailto:ary esperanto.org.ar" target=3D"_b= lank">ary esperanto.org.ar</a>&gt;</span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div><div></div><div>On 8/1/11 2:58 PM, Brad Anderson wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The NSIS script used to update the environment<br> variable (EnvVarUpdate) has the following warning [1]:<br> <br> &quot;Warning this code will replace paths rather than append if the existi= ng<br> path exceeds the maximum string length in the NSIS build you are using.<br> Some setup crash can also occurs.&quot;<br> <br> The default maximum string length is 1024. =A0There is a special build of<b= r> NSIS [2] which has a larger maximum string length (8192) that would help<br=

detects if the PATH will be overwritten instead of appended to and tells<br=

<br> I&#39;ve seen this issue complained about before online but<br> hadn&#39;t experienced it myself until recently. =A0It can be a rather<br> frustrating problem to experience as restoring your PATH isn&#39;t trivial<= br> because there is no way (that I know of) to look at what your PATH was<br> before it was destroyed and the PATH is often updated by installers (as<br> it is with dmd).<br> <br> [1]<br> <a href=3D"http://nsis.sourceforge.net/Environmental_Variables:_append,_pre= pend,_and_remove_entries#Warning" target=3D"_blank">http://nsis.sourceforge= .net/<u></u>Environmental_Variables:_<u></u>append,_prepend,_and_remove_<u>= </u>entries#Warning</a><br> [2] <a href=3D"http://nsis.sourceforge.net/Special_Builds" target=3D"_blank= ">http://nsis.sourceforge.net/<u></u>Special_Builds</a><br> <br> Regards,<br> Brad Anderson<br> </blockquote> <br></div></div> Hi Brad,<br> <br> IIRC I wrote the installer and I knew about the problem too because some pe= ople started complaining about it but I didn&#39;t know of the solution (ma= ybe at that moment the solution was not known). So good you found it :-)<br=

<br> What we can do is to copy this patched EnvVarUpdate function to the install= er script and use it, I think it&#39;ll be much more safe than to just hope= the system that runs the nsis script has the patched function or the speci= al build.<br> <br> What do you think? Could you make that change and do a pull request? (I don= &#39;t have a Windows machine near me anymore nor a VM).<br> </blockquote></div><br> </div></div></blockquote></div><br> --0015174beed469ba7e04a9766a9a--
Aug 01 2011
prev sibling next sibling parent "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
prev sibling 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 next sibling parent Brad Anderson <eco gnuk.net> writes:
--0015174beed49e195304a9804dc4
Content-Type: text/plain; charset=ISO-8859-1

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 --0015174beed49e195304a9804dc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 1, 2011 at 6:35 PM, Vladimir Panteleev <span dir=3D"ltr">&lt;<a= href=3D"mailto:vladimir thecybershadow.net">vladimir thecybershadow.net</a=
&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=

:1ex;"> <div class=3D"im">On Mon, 01 Aug 2011 20:58:08 +0300, Brad Anderson &lt;<a = href=3D"mailto:eco gnuk.net" target=3D"_blank">eco gnuk.net</a>&gt; wrote:<= br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> there is no way (that I know of) to look at what your PATH was before it wa= s destroyed and the PATH is often updated by installers (as it is with dmd)= .<br> </blockquote> <br></div> If you haven&#39;t rebooted your machine yet - Windows stores a backup copy= of the system registry hives for the &quot;last known good configuration&q= uot; boot feature. These copies are stored in C:\Windows\Repair (XP and bef= ore) or C:\Windows\System32\config\<u></u>RegBack (Vista and after). You wi= ll not be able to access these files directly, though - you&#39;ll need to = use a tool or risk a poweroff and boot from another OS. Once you have a rea= dable copy, you can &quot;mount&quot; the hives to an empty key in your reg= istry with RegEdit. PATH is located at HKEY_LOCAL_MACHINE\SYSTEM\<u></u>Cur= rentControlSet\Control\<u></u>Session Manager\Environment (though you won&#= 39;t see CurrentControlSet in the mounted hive, it&#39;s a symbolic link of= sorts to one of the ControlSetXXX keys).<br> =A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex;"><font color=3D"#888888"> -- <br> Best regards,<br> =A0Vladimir =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mailto:<= a href=3D"mailto:vladimir thecybershadow.net" target=3D"_blank">vladimir <u=
</u>thecybershadow.net</a><br>

.</div><div><br></div><div>Regards</div><div>Brad Anderson</div> --0015174beed49e195304a9804dc4--
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