Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#483 Windows installation overwritten PATH variable

closed
Mark Miesfeld
5
2012-08-14
2007-12-28
Anonymous
No
  • Version of ooRexx: 3.2.0.1
  • Operating System: Windows XP SP2
  • Details:
    I installed ooRexx via Windows installation package. As result my system-wide PATH variable altered by installer contained only ooRExx path. The installer has overwritten value of PATH instead of appending new path to the end.

Discussion

  • Mark Miesfeld
    Mark Miesfeld
    2007-12-28

    Logged In: YES
    user_id=191588
    Originator: NO

    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
    $2 value:
    $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"
    AddToPath_NTdoIt:
      StrCmp $R7 "true" AddToPath_AllUsers_doit
      ; writing registry for current user
      WriteRegExpandStr HKCU "Environment" "$R8" $0
      DetailPrint "$4 added to $R8 for Current User"
      Goto AddToPath_UserCont_doit
    AddToPath_AllUsers_doit:
      ; 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 ...

     
  • Mark Miesfeld
    Mark Miesfeld
    2007-12-29

    Logged In: YES
    user_id=191588
    Originator: NO

    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.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-03-31

    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.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-07-22

    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.

     
  • Mark Miesfeld
    Mark Miesfeld
    2010-02-22

    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.

     


Anonymous


Cancel   Add attachments