bugGNU Octave - Bugs: bug #50005, MXE Octave: using 8.3 file...

 
 

bug #50005: MXE Octave: using 8.3 file convention?

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Sat 07 Jan 2017 07:32:21 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Wont Fix Assigned to:  None
Originator Name:  Avinoam Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

Mike Miller <mtmiller>
Group Member
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.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 11 Jan 2017 09:20:37 PM UTC, comment #9: 

sorry minus sign should have been escaped as well

789_\-.:/\\]"


kire pudsje <kpc>
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

echo %HOME%| findstr /r "[^ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-.:/\\]" > NUL && (
  for %%I in ("%HOME%") do set HOME=%%~sI
)


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

kire pudsje <kpc>
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.

if not "%HOME: =_space_%" == "%HOME%" (
  for %%I in ("%HOME%") do set HOME=%%~sI
)


This however only checks for spaces. I read in that there has also been an issue with special characters.

kire pudsje <kpc>
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.

Philip Nienhuis <philipnienhuis>
Group Member
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.

John Donoghue <lostbard>
Group Member
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.

John Donoghue <lostbard>
Group Member
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.


Philip Nienhuis <philipnienhuis>
Group Member
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.

John Donoghue <lostbard>
Group Member
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?

John W. Eaton <jwe>
Group administrator
Sat 07 Jan 2017 07:32:21 PM UTC, original submission:  


In Octave 4.2:


>> which assert
'assert' is a function from the file D:\Octave\Octave-4.2.0\share\octave\4.2.0\m\testfun\assert.m


Using dev branch:


>> __octave_config_info__ ('hg_id')
ans = 53bb781d70c0
>> which assert
'assert' is a function from the file D:\Octave\OCTAVE~1.0_\share\octave\4.3.0+\m\testfun\assert.m


Also:


>> path

Octave's search path contains the following directories:

.
D:\Octave\OCTAVE~1.0_\lib\octave\4.3.0+\site\oct\x86_64-w64-mingw32
D:\Octave\OCTAVE~1.0_\lib\octave\site\oct\api-v51\x86_64-w64-mingw32
D:\Octave\OCTAVE~1.0_\lib\octave\site\oct\x86_64-w64-mingw32
D:\Octave\OCTAVE~1.0_\share\octave\4.3.0+\site\m
D:\Octave\OCTAVE~1.0_\share\octave\site\api-v51\m
D:\Octave\OCTAVE~1.0_\share\octave\site\m
D:\Octave\OCTAVE~1.0_\share\octave\site\m\startup
.....


Avinoam Kalma <avinoam>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by kpc (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jwe
  • -email is unavailable- added by avinoam (Submitted the item)
  • -email is unavailable- added by avinoam
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-27 mtmiller StatusNone Wont Fix
        Open/ClosedOpen Closed
    2017-01-07 jwe Carbon-Copy- Added lostbard
    2017-01-07 avinoam Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code