bugGNU Octave - Bugs: bug #53124, [MXE Octave] install in path that...

 
 

bug #53124: [MXE Octave] install in path that includes spaces

Submitted by:  None
Submitted on:  Mon 12 Feb 2018 01:34:50 AM UTC  
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  3 - Low Item Group:  Other
Status:  Ready For Test Assigned to:  None
Originator Name:  Paul Doerr Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
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)

Wed 25 Mar 2020 07:00:55 PM UTC, comment #35: 

First off, I am not so much opposed to installing Octave by default in "C:\Program Files".
But IMO it's going a bit fast. As the bug report title says, this bug is about installing Octave in paths containing spaces; not per sé about installing Octave in a particular directory that happens to have a space in its name.

It could be either an advantage or a disadvantage that users can't change Octave internals anymore; I guess it'll turn out be a mixed bag. We'll have to watch what happens once the first mxe-Octave installers are to be released (for Octave-6.*).

One of my thinking "lines" is that a big benefit of Octave's OSS status is that users can inspect and adapt the code, if possible easily. That's still possible but requires a few more steps.
Perhaps the install screen could inform users that the now default install location (C:\Program Files) has some implications.

IMO Matlab is not a good comparison. Its function files can't be changed as they are all .p files (translated .m files) and the .m files that are left only contain the help texts. The reason is undoubtedly that Matlab is proprietary and TMW wants to hide its code, in contrast to Octave.

@JohnD:
Yes I've been entering my system's admin password to be able to install Octave for many years now. It's just that this discussion brought back reminiscences that there used to be an alternative. I'll have a look in the makeinst_script.sh.in file, maybe that option can be resurrected?

Philip Nienhuis <philipnienhuis>
Project Member
Wed 25 Mar 2020 07:31:30 AM UTC, comment #34: 

I'd expect that the standard user wouldn't change core or package .m files usually.
Are the core and packaged files of Octave to be changed by a plain user? I am not sure if they are. It might be even worth pursuing to protect these files from accidental changes...
FWIW, this is also how core and package files of Matlab behave on Windows.

Package or core developers that want to edit these files on a regular basis are free to install Octave to anywhere they want (where changes to core and packaged files is allowed). If installed at the default location, these files can still be changed with elevated rights (either using Octave itself or another editor).

Markus Mützel <mmuetzel>
Project Member
Wed 25 Mar 2020 12:12:28 AM UTC, comment #33: 

And in english, "But isn't been there a long time too" would mean that it hasn't changed any time recently.

John Donoghue <lostbard>
Project Member
Tue 24 Mar 2020 11:11:15 PM UTC, comment #32: 

For the admin credentials, i believe they would come from the line in the nsis script:

RequestExecutionLevel admin

Im not sure when it was added, but looking back to the file in 2016, iut was still set the same.

Attempting to install any of the older installers on you current machine behaves differently to the latest?

There should also be the install for all user checkbox in the options page which controls the context:

  \${If} \$InstallAllUsers == \${BST_CHECKED}
    SetShellVarContext all
  \${Else}
    SetShellVarContext current
  \${Endif}

But isn't been there a long time too

John Donoghue <lostbard>
Project Member
Tue 24 Mar 2020 10:24:26 PM UTC, comment #31: 

One hitch is that editing function files is not possible - that is, they can't be saved unless the user has admin privileges or runs Octave with admin priviliges  (right click on the Octave shortcut, select "run as administrator", enter admin password and there you go - that is, if and only if the required "RunAs" service has been installed and is running).
An alternative way to adapt / edit / debug Octave .m function files (and OF functions shipped with mxe-octave) and run them, would be to explicitly shadow them in some way, by e.g., putting them in the cwd or in a subdir in the top of the path. For hidden functions (in private/ subdirs) that isn't so easy.

This makes me less certain if installing Octave in protected places like "C:\Program Files" is really such a good idea in the first place.
Installing software there is good for programs that aren't supposed to be changed or adapted by plain users. Are we convinced that Octave and its OF packages belong to this class of programs?

BTW currently the mxe installers always ask me for admin credentials, no matter where Octave gets installed - the UAC pops up before the NSIS installer is even visible. IIRC until some time ago the installer always asked for a local or global installation.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 19 Mar 2020 08:48:55 PM UTC, comment #30: 

Installing a package takes care of quite a few of those (unpacking, compiling, linking, moving files around).

IIRC there are related bug reports where specific issues were listed (I somehow felt this was a duplicate report). Once I have more time I'll search for them and try some more.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 19 Mar 2020 01:10:34 PM UTC, comment #29: 

I guess testing anything that involves calling out to other executables installed with Octave wouldn't hurt. E.g., packing/unpacking files, plotting with gnuplot, printing to different formats (gnuplot and qt), installing packages (that you've already done), ...

This is probably by far not a complete list.

Markus Mützel <mmuetzel>
Project Member
Wed 18 Mar 2020 07:57:26 PM UTC, comment #28: 

Builds & runs fine with the cset from comment #8.

Once installed in Windows __run_test_suite__.m yields 7 FAILS, but I think I saw those before.

Installing e.g., ocl-1.1.1.tar.gz also works fine (apart from build errors in the ocl package).

What else can be tested?

Philip Nienhuis <philipnienhuis>
Project Member
Mon 16 Mar 2020 11:54:20 AM UTC, comment #27: 

I pushed the patch from comment #8 here:
https://hg.octave.org/mxe-octave/rev/4d6716dcec28

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Sun 15 Mar 2020 11:09:52 PM UTC, comment #26: 

Fine by me

C:\Program Files\Octave\${VERSION}

or

C:\Program Files\Octave\Octave-${VERSION}

?

John Donoghue <lostbard>
Project Member
Sun 15 Mar 2020 04:26:31 PM UTC, comment #25: 

Installing level-set now fails with a different error in Octave 7.0:

>> pkg install -forge -verbose level-set
mkdir (C:\Users\Markus\AppData\Local\Temp\oct-gbPy48)
untar (C:\Users\Markus\AppData\Local\Temp\level-set-0.3.0-jnAYHF.tar.gz, C:\Users\Markus\AppData\Local\Temp\oct-gbPy48)
configure: loading site script /usr/local/etc/config.site
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ supports C++11 features by default... yes
configure: creating ./config.status
config.status: creating Makefile
make: Entering directory '/tmp/oct-gbPy48/level-set/src'
g++ -g -O2 -Wall -Wextra -Weffc++ -pedantic -fPIC -c FastMarching.cpp -o FastMarching.o
CXXFLAGS="-g -O2 -Wall -Wextra" C:/PROGRA~1/GNUOCT~1/OCTAVE~1.0/mingw64/bin/mkoctfile-7.0.0.exe --verbose -c Utils.cpp -o Utils.o
g++ -c -I/home/osboxes/Repositories/Octave/mxe-octave-1/usr/x86_64-w64-mingw32/include  -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include\octave-7.0
.0\octave\.. -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include\octave-7.0.0\octave -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include   -fopenmp -g -
O2 -Wall -Wextra    Utils.cpp -o Utils.o
CXXFLAGS="-g -O2 -Wall -Wextra" C:/PROGRA~1/GNUOCT~1/OCTAVE~1.0/mingw64/bin/mkoctfile-7.0.0.exe --verbose internal_fastmarching.cpp FastMarching.o U
tils.o -o __levelset_internal_fastmarching.oct
g++ -c -I/home/osboxes/Repositories/Octave/mxe-octave-1/usr/x86_64-w64-mingw32/include  -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include\octave-7.0
.0\octave\.. -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include\octave-7.0.0\octave -IC:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\include   -fopenmp -g -
O2 -Wall -Wextra    internal_fastmarching.cpp -o C:\Users\Markus\AppData\Local\Temp/oct-ZXxX9p.o
In file included from c:\progra~1\gnuoct~1\octave~1.0\mingw64\lib\gcc\x86_64-w64-mingw32\9.2.0\include\c++\cassert:44,
                 from internal_fastmarching.cpp:29:
internal_fastmarching.cpp: In lambda function:
internal_fastmarching.cpp:77:51: error: 'const class Array<long long int>' has no member named 'length'
   77 |                   && static_cast<dimensionT> (idx.length ()) == D);
      |                                                   ^~~~~~
internal_fastmarching.cpp: In lambda function:
internal_fastmarching.cpp:102:51: error: 'const class Array<long long int>' has no member named 'length'
  102 |                   && static_cast<dimensionT> (idx.length ()) == D);
      |                                                   ^~~~~~
make: *** [Makefile:60: __levelset_internal_fastmarching.oct] Error 1
make: Leaving directory '/tmp/oct-gbPy48/level-set/src'

error: pkg: error running 'make' for the level-set package.
error: called from
    configure_make at line 105 column 9
    install at line 196 column 7
    pkg at line 517 column 9

But the permission error seems to be solved. Good work!

@John: Do you think we could start installing to %PROGRAMFILES% on Windows now? Or should we better wait until after Octave 6 is out?

Markus Mützel <mmuetzel>
Project Member
Mon 24 Feb 2020 08:17:22 PM UTC, comment #24: 

I added https://hg.octave.org/mxe-octave/rev/cf1366413153 that 'mounts' /tmp to the normal users tempdir

John Donoghue <lostbard>
Project Member
Mon 24 Feb 2020 01:40:16 PM UTC, comment #23: 

Ok you need to set 3 variables.

TEMP
TMPDIR
TMP

John Donoghue <lostbard>
Project Member
Mon 24 Feb 2020 08:07:05 AM UTC, comment #22: 

I set the vars at the Octave command prompt using "setenv". I was using the GUI in case this should make a difference.
I don't remember exactly. But I think I didn't restart Octave after the "pkg install" failed initially. Instead I set the environment vars and tried again. Maybe there is some caching going on, so it didn't pick up the new vars on subsequent tries.

I'll try later if setting the vars in the vbs makes a difference in case this would help.

Markus Mützel <mmuetzel>
Project Member
Mon 24 Feb 2020 04:04:10 AM UTC, comment #21: 

How or should I say where do you set the vars - in octave or thevbs or bat file, or before that ?

John Donoghue <lostbard>
Project Member
Sun 23 Feb 2020 04:16:53 PM UTC, comment #20: 

I can confirm that configure succeeds if I add "read" and "change" permission for the group "users" to %OCTAVE_INSTALL%\tmp.

Setting %TMPDIR% and %TEMP% to D:\Temp still leads to the error in comment #16 here.

Markus Mützel <mmuetzel>
Project Member
Sun 23 Feb 2020 02:38:19 PM UTC, comment #19: 

Setting the var TMPDIR to the same place as TEMP fixes it:

setenv('TMPDIR', getenv('TEMP'))

There have been a couple of other reports I think where changing TEMP didnt appear to fix the issue. I wonder if both set would have fixed it.

I guess we should set TMPDIR to TEMP in the launch scripts. But anyone who wants to change TEMP will need change both unless there is a way force msys to use TEMP

John Donoghue <lostbard>
Project Member
Sun 23 Feb 2020 02:26:17 PM UTC, comment #18: 

Found the reason, but havent started looking for a fix yet.

There is a OCTAVE_INSTALL/tmp directory in the installed files, and if I change permissions of it to allow access for everything, I can see temp files appearing in it occasionally as configure runs - not all temp files - as most of those appear in the TEMP var folder.

With it set to allow anything, the pkg install works as it does when I install to c:\octave (at least in terms of success)

John Donoghue <lostbard>
Project Member
Sun 23 Feb 2020 01:30:11 PM UTC, comment #17: 

I reinstalled to c:\program files\gnu octave\* and get the same error you are seeing in comment #16.

If I install to c:\octave\* it doesnt do that and continues with the install and fails later on due to errors in source file compile as expected.

So at least for me, there seems to difference in the pkg install depending where octave was installed.

John Donoghue <lostbard>
Project Member
Sun 23 Feb 2020 10:31:41 AM UTC, comment #16: 

@lostbard: Installing level-set also fails here.
I ran "pkg install -forge -verbose level-set" and got the following:

>> pkg install -forge -verbose level-set

mkdir (C:\Users\Markus\AppData\Local\Temp\oct-6QQtKB)
untar (C:\Users\Markus\AppData\Local\Temp\level-set-0.3.0-Pe5AzJ.tar.gz, C:\Users\Markus\AppData\Local\Temp\oct-6QQtKB)
./configure: line 1377: cannot create temp file for here-document: Permission denied
./configure: line 1389: cannot create temp file for here-document: Permission denied
./configure: line 1424: cannot create temp file for here-document: Permission denied
./configure: line 1586: cannot create temp file for here-document: Permission denied
./configure: line 1590: cannot create temp file for here-document: Permission denied
./configure: line 1594: cannot create temp file for here-document: Permission denied
./configure: line 1598: cannot create temp file for here-document: Permission denied
./configure: line 1602: cannot create temp file for here-document: Permission denied
./configure: line 1606: cannot create temp file for here-document: Permission denied
configure: loading site script /usr/local/etc/config.site
checking for g++... g++
./configure: line 1866: cannot create temp file for here-document: Permission denied
checking whether the C++ compiler works... no
sed: can't read conftest.cpp: No such file or directory
configure: error: in `/c/Users/Markus/AppData/Local/Temp/oct-6QQtKB/level-set/src':
configure: error: C++ compiler cannot create executables
See `config.log' for more details

error: pkg: error running the configure script for level-set.
error: called from
    configure_make at line 88 column 9
    install at line 196 column 7
    pkg at line 517 column 9

I stepped through pkg/private/install.m and inspected the temporary folder when the error was caught. See the attachment for its content.
An excerpt from the config.log:

configure:1882: checking whether the C++ compiler works
configure:1904: g++    conftest.cpp  >&5
g++.exe: error: conftest.cpp: No such file or directory
g++.exe: fatal error: no input files
compilation terminated.
configure:1908: $? = 1
configure:1946: result: no
configure: failed program was:
configure:1951: error: in `/c/Users/Markus/AppData/Local/Temp/oct-mVobq7/level-set/src':
configure:1953: error: C++ compiler cannot create executables

Setting %TEMP% to D:\Temp doesn't make a difference.

Fwiw, I'm seeing the same error when I run the command in Octave 5.2.0 installed with the released installer. So it's probably unrelated to the change here.

(file #48477)

Markus Mützel <mmuetzel>
Project Member
Sun 23 Feb 2020 03:22:05 AM UTC, comment #15: 

Not sure if its me, or something weired going on - I created a octave 7 mxe using a octave tarball from the repo at rev https://hg.octave.org/octave/rev/c1ca9b6903cd

With the patch from here applied it installs ok and runs and does the tests ok, but on attempting to run pkg install:

pkg install -forge level-set

It fails attempting to create files at the start of configure during the install.

Rebuilding the installer without the patch below installed, and it runs as normal (a known fail during the compile of the code in this case)

Im going to reapply the patch and see if happens again

Windows preventing certain programs creating files in temp depending where they are running from ?

The only virus stuff on this (VM) is the windows defender that it comes with - I havent tried turning it off yet.

John Donoghue <lostbard>
Project Member
Sat 22 Feb 2020 12:27:17 PM UTC, comment #14: 

I wonder if the default to global for windows packages should also get resolved

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44548

I like the C:\Program Files\Octave\${VERSION} but it doesnt really matter t me

John Donoghue <lostbard>
Project Member
Sat 22 Feb 2020 09:34:27 AM UTC, comment #13: 

I re-installed Octave 7 (hg id 865f8ddb2c78) with pre-compiled packages (minus the ones that are incompatible at the moment) to "C:\Program Files\GNU Octave\Octave-7.0.0".
Trying to re-install the geometry package as an example, I ran into the following:

>> pkg install -forge geometry
clipper.cpp: In function 'void ClipperLib::InitEdge(ClipperLib::TEdge*, ClipperLib::TEdge*, ClipperLib::TEdge*, const ClipperLib::IntPoint&)':
clipper.cpp:750:34: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct ClipperLib::TEdge'; use assignment or
value-initialization instead [-Wclass-memaccess]
  750 |   std::memset(e, 0, sizeof(TEdge));
      |                                  ^
clipper.cpp:95:8: note: 'struct ClipperLib::TEdge' declared here
   95 | struct TEdge {
      |        ^~~~~
error: couldn't delete directory C:\Program Files\GNU Octave\Octave-7.0.0\mingw64\share\octave\packages\geometry-4.0.0: Permission denied
error: called from
    uninstall at line 132 column 11
    install at line 211 column 9
    pkg at line 513 column 9

Executing the same command when Octave is started with elevated rights, I see the following:

>> pkg install -forge geometry

clipper.cpp: In function 'void ClipperLib::InitEdge(ClipperLib::TEdge*, ClipperLib::TEdge*, ClipperLib::TEdge*, const ClipperLib::IntPoint&)':
clipper.cpp:750:34: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct ClipperLib::TEdge'; use assignment or
value-initialization instead [-Wclass-memaccess]
  750 |   std::memset(e, 0, sizeof(TEdge));
      |                                  ^
clipper.cpp:95:8: note: 'struct ClipperLib::TEdge' declared here
   95 | struct TEdge {
      |        ^~~~~
C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\ming
w64\bin\makeinfo line 345.

C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\ming
w64\bin\makeinfo line 345.

[snip]

C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\ming
w64\bin\makeinfo line 345.

C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at C:\PROGRA~1\GNUOCT~1\OCTAVE~2.0\ming
w64\bin\makeinfo line 345.

For information about changes from previous versions of the geometry package, run 'news geometry'.

The makeinfo issue is probably something different we should look into. But overall it looks like the package installed fine.
Loading the package and running "pkg test geometry" seems to work fine as well. The tests (minus the known issues with @svg) also succeed when subsequently running Octave without elevated rights.

Is it OK if users would need to run Octave with elevated rights when they want to update global packages?
I think it is. Especially taking PCs into account that are shared between multiple users.

Btw, I'm seeing the same already for Octave 5.2.0 installed with the official installer in "C:\Octave\Octave-5.2.0":

>> pkg install -forge geometry

error: the following dependencies were unsatisfied:
   geometry needs matgeom >= 1.0.0
>> pkg install -forge matgeom
couldn't create installation directory C:\Octave\OCTAVE~1.0\mingw64\share\octave\packages\matgeom-1.
2.2 : Permission denied
error: called from
    install>copy_files at line 490 column 7
    install at line 225 column 7
    pkg at line 441 column 9
>>

And when running with elevated rights:

>> pkg install -forge matgeom

C:\Octave\OCTAVE~1.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at
C:\Octave\OCTAVE~1.0\mingw64\bin\makeinfo line 345.

C:\Octave\OCTAVE~1.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at
C:\Octave\OCTAVE~1.0\mingw64\bin\makeinfo line 345.

For information about changes from previous versions of the matgeom package, run 'news matgeom'.

Markus Mützel <mmuetzel>
Project Member
Fri 21 Feb 2020 08:25:55 PM UTC, comment #12: 

Keep in mind that the user can always customize the install directory to whatever they want, if it turns out later that there are problems. IMO, that means the default isn't that important, and might as well be changed to be C:\Program Files\Octave\${VERSION} now or similar.

I have recently been testing Octave in a Windows 10 VM, and I have only ever installed it in C:\Program Files\Octave\5.2.0, and haven't run into any problems yet related to that choice.

Mike Miller <mtmiller>
Project Administrator
Fri 21 Feb 2020 08:07:45 PM UTC, comment #11: 

FWIW, I always install Octave in C:\Programs\Octave\Octave-<version-date>. No issues there with installed packages either. I usually adapt makeinst_script.sh.* to this end (and adapt the Start Menu shortcuts in there as well).
C:\Programs is where I have several other SW installed that doesn't always like spaces (usually SW ported from *nix).

Philip Nienhuis <philipnienhuis>
Project Member
Fri 21 Feb 2020 02:44:02 PM UTC, comment #10: 

I re-visited bug #49718 and closed it as fixed.

Tbh, I've done only very minor testing. I'll do some more testing when I come around to it.

Markus Mützel <mmuetzel>
Project Member
Fri 21 Feb 2020 01:38:34 PM UTC, comment #9: 

I think there are still issues if we used '(' and ')', isnt there? (Bug #49718)

Also, even though it is probally already an issue - I wonder if there would any new permissions errors with things like installing packages since it defaults to the global install space in windows ?

John Donoghue <lostbard>
Project Member
Fri 21 Feb 2020 11:33:09 AM UTC, comment #8: 

Moving towards Octave 6.1, should we default to a location in %PROGRAMFILES% (or %PROGRAMFILES(X86)%) for the installation folder on Windows?

Installing a 64bit Octave on a 64bit Windows 10 with the attached patch works for me and the test suite completes.

(file #48460)

Markus Mützel <mmuetzel>
Project Member
Wed 14 Feb 2018 08:01:20 AM UTC, comment #7: 

Also: The 8.3 file names are used optionally only by NTFS file system. [1]
If I remember correctly, I encountered a laptop with pre-installed Windows 10 Home where that option was turned of by default on the second hard drive partition (D:). If we rely on that feature, we could see errors on systems where it is turned off on the partition where Octave is installed.

[1] https://support.microsoft.com/de-de/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions

Markus Mützel <mmuetzel>
Project Member
Wed 14 Feb 2018 07:49:10 AM UTC, comment #6: 

Good news that Octave can be installed to paths with spaces now. I didn't know that yet.
However, it still stumbles upon folders with non-ASCII characters. The %ProgramFiles% variable is localized on some Windows version (e.g. the default is C:\Programme on a German Windows XP). I don't know for sure. But that path might contain non-ASCII characters on other locales.
Maybe we should still wait before we install Octave to that location by default.

Markus Mützel <mmuetzel>
Project Member
Wed 14 Feb 2018 02:11:45 AM UTC, comment #5: 

Installing to paths with spaces sounds good to me.

Previous issues I believe has been with the printing/ghostscript:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=41140

However, I believe that was before the change where it uses the 8.1 format path name, which may make it never see spaces anyway.

John Donoghue <lostbard>
Project Member
Tue 13 Feb 2018 10:59:51 PM UTC, comment #4: 

Can we also change the default install suggestion to be C:\Program Files\Octave\Octave-${OCTAVE_VERSION}? I think that should be the default, assuming everything works.

Mike Miller <mtmiller>
Project Administrator
Tue 13 Feb 2018 10:59:44 PM UTC, comment #3: 

Oh, the tmpdir problem happened because the test suite does

setenv ("TMPDIR", "__MY_TMP_DIR__");

and doesn't restore the previous value (if any) when the test is done.

So that is a bug in the test suite, not a problem with ghostscript or Octave's code for printing plots.

John W. Eaton <jwe>
Project Administrator
Tue 13 Feb 2018 10:55:12 PM UTC, comment #2: 

I just took an installed copy of Octave and moved it from "C:\Octave" to "C:\Program Files\Octave" and ran the test suite with _run_test_suite_.  The results look fine.  OTOH, I would expect most everything to be OK since most tests don't touch the filesystem except for finding .m files, and that appears to work fine.  The things I might expect to have problems are any system commands.  But the pager and gnuplot appear to work OK, at least as much as I tested them.  I did see a message from ghostscript about not being able to open a temporary file when I tried to print a plot to a PDF file.

I'd like to remove the restriction in the installer and just fix any problems that show up.  Any objections?

John W. Eaton <jwe>
Project Administrator
Mon 12 Feb 2018 06:53:46 AM UTC, comment #1: 

Yes, the installer intentionally checks and reports "Octave should not be installed to a destination folder containing spaces. Please select another destination."

I think it should allow installation to any path, but I don't have access to Windows to test. Are you able to run through the test suite and evaluate functionality and packages and make sure they all work?

Mike Miller <mtmiller>
Project Administrator
Mon 12 Feb 2018 01:34:50 AM UTC, original submission:  

The 64bit MS Windows installer will not accept an install path that includes spaces, e.g. Program Files/Octave.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48477:  oct-mVobq7.zip added by mmuetzel (234KiB - application/x-zip-compressed)
file #48460:  bug53124_install_programfiles.patch added by mmuetzel (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 mmuetzel (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 mtmiller (Posted a comment)
  • -email is unavailable- added by None (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-03-16 mmuetzel StatusPatch Submitted => Ready For Test
    2020-02-23 mmuetzel Attached File- => Added oct-mVobq7.zip, #48477
    2020-02-21 mmuetzel Attached File- => Added bug53124_install_programfiles.patch, #48460
        StatusNeed Info => Patch Submitted
        Release4.2.1 => dev
        SummaryOctave will not accept an install path that includes any spaces => [MXE Octave] install in path that includes spaces
    2018-02-12 mtmiller CategoryNone => Configuration and Build System
        Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
        StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5