Fri 27 Jan 2017 01:45:00 AM UTC, comment #11:
So it seems like this was done intentionally and it's not causing any problems, closing as won't fix since there doesn't seem to be any reason to leave this open.
|
Fri 13 Jan 2017 04:42:07 PM UTC, comment #10:
As to my comment #6:
Installing in a path with spaces may work, but installing in e.g., "C:\Program Files" (for 64-bit Octave) or "C:\Program Files (X86)" (32-bit Octave) leads to several problems that AFAICS are related to file permissions when Octave is run as ordinary user.
For example, a command like "edit xlsread" does not work although "which xlsread" returns the file location. When run with administrator this does work fine.
So for mxe-octave the OF packages may have to be installed in a user's home directory or elsewhere in a path not protected by system policies.
Aother thing:
Is this really a regression? As JohnD pointed out the effects are limited and IMO on the whole the balance is positive.
|
Wed 11 Jan 2017 09:20:37 PM UTC, comment #9:
sorry minus sign should have been escaped as well
|
Wed 11 Jan 2017 09:05:23 PM UTC, comment #8:
The following lines should only replace to 8.3 format if it encounters a character not in the list below
Please note that the regexp CANNOT be replaced by A-Za-z, since Microsoft in all their wisdom decided that the A-Z ranges include accented characters
|
Wed 11 Jan 2017 07:38:49 PM UTC, comment #7:
In one of the posts in bug #49765, I suggested to only replace the path to 8.3 format when necessary. However this did not make it to the patch.
This however only checks for spaces. I read in that there has also been an issue with special characters.
|
Sun 08 Jan 2017 09:31:41 PM UTC, comment #6:
Some experimenting here indicates that this change finally seems to offer a solution for installing Octave in paths with spaces (e.g., "C:\Program Files" on Windows).
Yet I think more testing is required to confirm this.
I had to comment out the relevant stanza in makeinst_script.sh and create an installer after that.
Installing octave as administrator in C:\Program Files (where the 64-bit programs are to be installed) worked fine on my Windows 7 box.
Afterwards I installed the OF-octclip package (a binary package) and that went quite well; but very slow compared to doing the same as ordinary user (and Octave in a path without spaces) - I suppose it has to do with the administrator status.
Installing the mapping package (invoking mkoctfile) also goes fine, until the file copying / doc generating stage where Octave seems to hang forever. But it finally worked.
|
Sun 08 Jan 2017 12:32:12 AM UTC, comment #5:
... With OCTAVE_HOME set the launch script, not in any build / configure of octave itself.
|
Sun 08 Jan 2017 12:30:07 AM UTC, comment #4:
Really the only place they are hard coded is in the env variable OCTAVE_HOME, which is also during package rebuild when installing octave.
Octave itself then uses that path to set the others, and doesnt stop use of long path names - just doesnt use it for the octave path.
|
Sat 07 Jan 2017 10:06:42 PM UTC, comment #3:
I was a bit surprised about this as well initially.
Later on, after just working with mxe-octave as it turned out to be, I found no issues as regards functionality - yet, that is :-)
Admittedly it is a bit of a rough change (but in JohnD's defense: I could have come up with it myself :-) )
Nonetheless I'd wish I could see the "real" (long) paths that are now mangled into 8.3 format, but looking at the cset I suppose they're "hard-coded" in the mxe build and not available anymore.
Of the "special character bugs" mentioned by JohnD here are several duplicates.
BTW I haven't tried yet but it may well be that one can install Octave now in paths containing spaces w/o encountering issues.
|
Sat 07 Jan 2017 08:24:28 PM UTC, comment #2:
It goes with http://hg.octave.org/mxe-octave/rev/8f71549f53b9
and for https://savannah.gnu.org/bugs/?49765
There was another another bug I cant find that is when special character are used in the install path which should also be fixed by it.
Ie: it uses the 8.3 path to ensure that no special characters are in the path (or home env setting)
Result is that it uses 8.3 path names - not a bug, but a difference from previous.
|
Sat 07 Jan 2017 07:41:05 PM UTC, comment #1:
That change appears to have been made here:
http://hg.octave.org/mxe-octave/rev/a45374f7d9a3
However, there's no explanation of why this change was needed or whether it can be configured.
John D, can you comment?
|
Sat 07 Jan 2017 07:32:21 PM UTC, original submission:
In Octave 4.2:
Using dev branch:
Also:
|