bugGNU Octave - Bugs: bug #59053, 6.0.90a: invalid path in Octave...

 
 

bug #59053: 6.0.90a: invalid path in Octave desktop shortcuts if install dir was changed

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Tue 01 Sep 2020 06:28:27 PM UTC  
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  None Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  Open
Release:  6.0.90 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 17 Sep 2020 09:14:55 PM UTC, comment #13: 

Yeah would imagine the fact there is no uninstall information is probally the culprit. Without the info in the uninstall registry, it cant know where the installs are.

Ive updated the script I previously attached that should display all of the installations from registry and the path values it is assuming it can get.

The startmenu shortcut setting should be easy enough to add as support for it is in NSIS already - I think is just a matter of enabling the correct page.

(file #49805)

John Donoghue <lostbard>
Project Member
Thu 17 Sep 2020 07:18:37 PM UTC, comment #12: 

What changes? Not so very much.
A list of them with my motives:

I backed out 4d6716dcec28 - install to Program Files by default. IMO an impractical location for developers as overwriting adapted or debugged .m files requires admin credentials. Using the "Install only for me" option Octave ends up in a long path in Programdata, away from most other SW that I keep in C:\Programs.
See also next point below:

In makeinst_script.sh (after running .configure), I:

  • Adapted Installdir to C:\Programs\Octave\Octave-$VERSION. I got fed up with always having to completely replace the install path, now I only have to append today's date, and I was too lazy to sort out how to automate even that (should be simple I guess).
  • Commented out most lines in the uninstall section, left only writing uninstall.exe active. That saves me cleaning up registry entries when having several dev versions installed alongside each other; otherwise the last installed version's registry entries are in the way each time I want to install a new crossbuild.
  • In the Shortcuts section, changed all Start Menu references from (s/th like) %MSPrograms\\GNU Octave\\ to %MSPrograms\\Edu\\Math\\GNU Octave\\  (IMO we still have to find a way to make that location editable. For plain vanilla Windows 10 it's no big deal, but I also use the Classic Start menu, and still have Windows 7 Enterprise at work, and then it counts.)

and that's it.
W.r.t. to this bug report I suppose only the inactive uninstall stuff may be suspect.

BTW:
Yes I know I can make zip archives rather than .exes and unpack them anywhere. But the installer has all post-install stuff automated and makes nice Start Menu entries and desktop shortcuts.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 17 Sep 2020 11:44:28 AM UTC, comment #11: 

The windows install registry has requirements on the format of version numbers, and as long as they dont conflict, they should coexist fine - with the exception of the shared desktop icon

Can you provide details on what changes you make to the installer/install info for your purposes

John Donoghue <lostbard>
Project Member
Wed 16 Sep 2020 09:37:21 PM UTC, comment #10: 

"cluttering desktop" - sounds subjective to me; but OK. IMNSHO users can tap the Del key on desktop shortcuts they don't like :-)
I'd suppose most users expect multiple programs (versions) leading to equally multiple icons.

Yes the original bug (see comment #0) still stands, but AFAIU it shifted a bit to robustness of the procedure to detect and handle other Octave installations.

I'm repeating myself, but I'm having trouble to understand why multiple octave installations can't just ignore each other and coexist peacefully. All that is needed is a version number in shortcuts and maybe in the registry. It looks like precisely that interaction between installations is fragile and causing trouble here.
It can be argued validly that I adapted installer parts, fine. Yet I think an official installer should be sufficiently robust to not get confused by my (slightly) adapted installations. (if that is the culprit - we don't know yet)

@John:
Reading back comment #8, do you want me to repeat the check with the adapted winqueryreg call?

Philip Nienhuis <philipnienhuis>
Project Member
Wed 16 Sep 2020 08:24:12 PM UTC, comment #9: 

Octave used to have versioned shortcuts (for example, Octave-4.2.2), but this could end up cluttering the user's desktop if they had several installed versions.

So, we switched to a single desktop shortcut which points to the latest installed version.  Any other installed versions of Octave can be started through the Start menu or the user can make their own desktop shortcut to a specific version.

Is there a specific bug that still needs resolving for this report?

Rik <rik5>
Project Administrator
Tue 08 Sep 2020 09:39:42 PM UTC, comment #8: 

I think the desktop file used to be versioned but was changed to be unversioned at some point - I cant remember the reason

By the way, the script I gave ealier had a typo -

 installpath = winqueryreg1(rootpath,[keypath '\' octave_version],
'InstallLocation');

should be

 installpath = winqueryreg(rootpath,[keypath '\' octave_version],
'InstallLocation');

I was testing to verify the fall over was working and forgot to change it back.

John Donoghue <lostbard>
Project Member
Tue 08 Sep 2020 09:20:24 PM UTC, comment #7: 

I think  I can follow; thanks for the explanation.
What you describe may be the reason that long ago I started hacking out that install info as it was in the way when there are several other Octave installations present; at least that was the case some time ago.

Admittedly the setup I have isn't a regular one for sure, but I think Octave installers could be more immune to other installations and vice versa.

For one, the newly installed desktop shortcut is always called e.g.,"GNU Octave (GUI)" but has no version info so overwrites desktop shortcuts from earlier installed Octaves, even different versions. Same for the Start Menu shortcuts.
I usually rename the desktop shortcuts to include the creation date (e.g., MMDD) to prevent it being overwritten by the next trial installer I built.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 08 Sep 2020 08:59:46 PM UTC, comment #6: 

They expect the uninstall information to have been saved in the registry with the rest if the uninstall info and attempts to update the ddesktop shortcut to use the latest (highest) octave version.

For new octave versions, there is a InstallPath value, for older values it tries to use the UninstallString to find the path.

I guess it could have an additional fail catch at that point if neither of those exist, assume its not a 'valid' octave install on uninstall, or during install just use the current install path.

John Donoghue <lostbard>
Project Member
Tue 08 Sep 2020 08:22:41 PM UTC, comment #5: 

GNU Octave, version 6.0.90
Copyright (C) 2020 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

Processing <HOME>/.octaverc
linear-algebra load time = 0.124800
signal load time = 0.499204
io load time = 1.606809
mapping load time = 0.982807
Processing <HOME>/.octaverc complete
Total .octaverc processing time = 3.385221

>> octave_version = '';
rootpath = 'HKCU';
keypath = 'SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall';
[ok,txt] = system(sprintf('reg query %s\\%s', rootpath, keypath));
keys = strsplit(txt, {"\n", "\r"}, 'COLLAPSEDELIMITERS', true);
for i=1:length(keys)
  key = keys{i};
  if length(key) > 1
    tmp = strsplit(key, '\');
    if length(tmp) > 1 && strncmpi(tmp{end}, "octave", 6)
      octave_version = tmp{end};
    endif
  endif
endfor

>> try
  installpath = winqueryreg1(rootpath,[keypath '\' octave_version],
'InstallLocation');
catch
  installpath = winqueryreg(rootpath,[keypath '\' octave_version],
'UninstallString');
  [installpath,~] = fileparts(installpath);
  [installpath,~] = fileparts(installpath);
  installpath = strrep(installpath ,'"', '');
end_try_catch
printf("desktop octave path= %s\n", installpath)

error: winqueryreg: no value found for 'UninstallString' at HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Octave-7.0.0 (Local).
>>

I have several local Octave releases installed, 4.2.0, 5.2.0, 6.0.90a (I think all "formal" binaries) and about 2-3 dev versions. In those dev versions I have stripped most of the uninstall stuff in makeinst_script.sh and they have several other mods (install paths, Start Menu paths).

It looks like the 6.0.90a installed Octave picks up, or tries to pick up, the dev versions' info (i.e., latest installation before 6.0.90a, which was a 7.0.0).

Am I right to conclude that it seems that current Windows installers (I mean the "official" ones, not the modified I make) expect no other Octave installations?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 08 Sep 2020 07:51:05 PM UTC, comment #4: 

It doesnt seem to to do it for me - are thier other local installs on your computer ?

If you run the following, what does it display:

octave_version = '';
rootpath = 'HKCU';
keypath = 'SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall';
[ok,txt] = system(sprintf('reg query %s\\%s', rootpath, keypath));
keys = strsplit(txt, {"\n", "\r"}, 'COLLAPSEDELIMITERS', true);
for i=1:length(keys)
  key = keys{i};
  if length(key) > 1
    tmp = strsplit(key, '\');
    if length(tmp) > 1 && strncmpi(tmp{end}, "octave", 6)
      octave_version = tmp{end};
    endif
  endif
endfor

try
  installpath = winqueryreg1(rootpath,[keypath '\' octave_version], 'InstallLocation');
catch
  installpath = winqueryreg(rootpath,[keypath '\' octave_version], 'UninstallString');
  [installpath,~] = fileparts(installpath);
  [installpath,~] = fileparts(installpath);
  installpath = strrep(installpath ,'"', '');
end_try_catch

printf("desktop octave path= %s\n", installpath)

John Donoghue <lostbard>
Project Member
Tue 08 Sep 2020 05:31:26 PM UTC, comment #3: 

The affected shortcuts mention "(Local)" in their name.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 08 Sep 2020 04:05:41 PM UTC, comment #2: 

Also to be clear, you are doing a local install, and its modifying the non local desktop shortcuts ?

John Donoghue <lostbard>
Project Member
Tue 08 Sep 2020 03:49:44 PM UTC, comment #1: 

From memory, we try to detect the latest version of octave and set the desktop icon to that, so I guess its not doing that correctly somewhere.

The start menu doesnt do the lookup as its the menu items are for that installation only.

John Donoghue <lostbard>
Project Member
Tue 01 Sep 2020 06:28:27 PM UTC, original submission:  

When I adapt the installation directory to where I usually put Octave (under C:\Programs\Octave\), the desktop shortcuts get an invalid location so won't start Octave:

%SYSTEMROOT%\system32\wscript.exe "\octave.vbs" --gui

The shortcuts in the Start Menu are OK, e.g.,

%SYSTEMROOT%\system32\wscript.exe "C:\Programs\Octave\Octave-6.0.90a\octave.vbs" --gui

(local install, "Just for me")
octave-6.0.90a-w64-installer.exe

Further info:
I've seen this for quite a while now with my dev Octave crossbuilds, but as I always amend tools/make_installscript.sh I figured it was my own problem.
But it turns out this also happens with a crossbuild from alpha.gnu.org

Philip Nienhuis <philipnienhuis>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49805:  scan_reg.m added by lostbard (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-18 rik5 Carbon-CopyRemoved 72865 => -
    2020-09-17 lostbard Attached File- => Added scan_reg.m, #49805

    Back to the top


    Powered by Savane 3.5