Re: Windows installer replaces the PATH variable

[Elliott S. <ell...@gm...>]

On Wed, Apr 20, 2011 at 4:58 PM, Elliott Slaughter <
ell...@gm...> wrote:

> On Wed, Apr 20, 2011 at 4:53 PM, Anton Vodonosov <avo...@ya...>wrote:
>
>>
>>
>> 16.04.2011, 11:06, "Elliott Slaughter" <ell...@gm...>:
>> >
>> > Anton,
>> >
>> > Could you please try the following test installers? Since I am unable to
>> reproduce the bug, I can't meaningfully test this on my own.
>> >
>> > Installer (1) below is intended to fix the bug. Installer (2) is a
>> sanity check to make sure the bug is still present when the fix is absent.
>> >
>> > (1) http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix.exe
>> >
>> > (2)
>> http://elliottslaughter.net/files/clisp-2.49+-win32-install-orig.exe
>> >
>> > *Please* back up your PATH (user and system) variables before trying
>> either of the above.
>> >
>> > Note that the actually CLISP that gets installed is quite broken--there
>> is a dll missing, among other things.
>> >
>> > Thanks.
>> >
>> > --
>> > Elliott Slaughter
>> >
>> > "Don't worry about what anybody else is going to do. The best way to
>> predict the future is to invent it." - Alan Kay
>>
>> Hello Elliott,
>>
>> Both installers replace my PATH.
>>
>> I did some investigations and found the reason. I have very long value of
>> the PATH variable.
>>
>> If the PATH lenght >= 1024 characters, it is replaced by the installer.
>>
>
> Thank you for looking into this.
>
> I'll try to confirm your results and see if I can find a fix.
>

Unfortunately, it looks like the 1024 character limit is built into NSIS.

http://nsis.sourceforge.net/Talk:Environmental_Variables:_append,_prepend,_and_remove_entries

The prescribed solution to get around this is apparently to rebuild NSIS
from source, or use special binaries built. The binaries below set the limit
to 8192 characters.

http://nsis.sourceforge.net/Special_Builds

I don't like this situation at all; among other things it means that the
packager/maintainer needs to know about and use special builds of NSIS.
Also, the script (at least the way it is written right now) has no way of
making sure the builder is using the large string build of NSIS, and an
unsuspecting CLISP packager might accidentally use the normal NSIS build
without knowing. On top of that, the situation could theoretically reappear
(with 8192 length strings instead of 1024), although it might be highly
unlikely.

I'm hoping to at least find a way to check dynamically if the string is too
long and avoid smashing PATH. I don't know if there will be any better
solution until a new version of NSIS comes out.

-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it." - Alan Kay