bugGNU Octave - Bugs: bug #49718, Octave crashes on print/saveas etc...

 
 

bug #49718: Octave crashes on print/saveas etc when installed on a directory with parenthesis

Submitted by:  None
Submitted on:  Sun 27 Nov 2016 09:09:50 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Ready For Test Assigned to:  None
Originator Name:  Vero 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)

Sun 10 Nov 2019 10:04:49 AM UTC, comment #64: 

This bug was originally about errors when using some specific characters (a.o. spaces and brackets) in files or paths when printing.
I opened a new report about the failing formats on Windows (bug #57197).
Sorry for having diverted the discussion here earlier.

Markus Mützel <mmuetzel>
Project Member
Tue 05 Nov 2019 08:42:14 PM UTC, comment #63: 

this pdflatex error must have been bug #57174

( https://savannah.gnu.org/bugs/?57174 )

now appears to be fixed.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 04 Nov 2019 11:56:54 PM UTC, comment #62: 

WRT Fedora buildbots failing -- this is something new.
Running make V=1 (i.e. not parallel make) results in:

/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-fedora/build/../src/doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'plot3', 'pdf');"
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbotu'
/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-fedora/build/../src/doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'extended', 'pdf');"
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbotu'

kpathsea: Running mktexfmt pdflatex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order):
mktexfmt:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
mktexfmt:   /home/buildbotu/.texlive2019/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under /home/buildbotu/fc25-x86_64/gcc-fedora/build/doc/.texmf-var/web2c
mktexfmt [INFO]: --- remaking pdflatex with pdftex
mktexfmt: running `pdftex -ini   -jobname=pdflatex -progname=pdflatex -translate-file=cp227.tcx *pdflatex.ini' ...
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (INITEX)
restricted \write18 enabled.
(/usr/share/texlive/texmf-dist/web2c/cp227.tcx)
entering extended mode
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/pdflatex.ini
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex)
(/usr/share/texlive/texmf-dist/tex/latex/base/latex.ltx
(/usr/share/texlive/texmf-dist/tex/latex/base/texsys.cfg)
./texsys.aux found


\@currdir set to: ./.


Assuming \openin and \input
have the same search path.


Defining UNIX/DOS style filename parser.

catcodes, registers, parameters,
LaTeX2e <2018-12-01>
hacks, control, par, spacing, files, font encodings, lengths,
====================================

Local config file fonttext.cfg used

====================================
(/usr/share/texlive/texmf-dist/tex/latex/base/fonttext.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/fonttext.ltx
=== Don't modify this file, use a .cfg file instead ===

(/usr/share/texlive/texmf-dist/tex/latex/base/omlenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/t1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmss.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmtt.fd)))
====================================

Local config file fontmath.cfg used

====================================
(/usr/share/texlive/texmf-dist/tex/latex/base/fontmath.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/fontmath.ltx
=== Don't modify this file, use a .cfg file instead ===

(/usr/share/texlive/texmf-dist/tex/latex/base/omlcmm.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/omscmsy.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/omxcmex.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ucmr.fd)))
====================================

Local config file preload.cfg used

=====================================
(/usr/share/texlive/texmf-dist/tex/latex/base/preload.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/preload.ltx)) page nos., x-ref,
environments, center, verbatim, math definitions, boxes, title, sectioning,
contents, floats, footnotes, index, bibliography, output,
===========================================
Local configuration file hyphen.cfg used
===========================================
(/usr/share/texlive/texmf-dist/tex/generic/babel/hyphen.cfg
(/usr/share/texlive/texmf-dist/tex/generic/babel/switch.def)
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/dumyhyph.tex)
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/zerohyph.tex))
(/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu)
(/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu))
) )
Beginning to dump on file pdflatex.fmt
(preloaded format=pdflatex 2019.11.4)
5438 strings of total length 72583
50981 memory locations dumped; current usage is 144&50807
3766 multiletter control sequences
\font\nullfont=nullfont
\font\OMX/cmex/m/n/10=cmex10
\font\tenln=line10
\font\tenlnw=linew10
\font\tencirc=lcircle10
\font\tencircw=lcirclew10
\font\OT1/cmr/m/n/5=cmr5
\font\OT1/cmr/m/n/7=cmr7
\font\OT1/cmr/m/n/10=cmr10
\font\OML/cmm/m/it/5=cmmi5
\font\OML/cmm/m/it/7=cmmi7
\font\OML/cmm/m/it/10=cmmi10
\font\OMS/cmsy/m/n/5=cmsy5
\font\OMS/cmsy/m/n/7=cmsy7
\font\OMS/cmsy/m/n/10=cmsy10
3633 words of font info for 14 preloaded fonts
14 hyphenation exceptions
Hyphenation trie of length 6081 has 183 ops out of 35111
  2 for language 1
  181 for language 0
0 words of pdfTeX memory
0 indirect objects
No pages of output.
Transcript written on pdflatex.log.
mktexfmt [INFO]: /home/buildbotu/fc25-x86_64/gcc-fedora/build/doc/.texmf-var/web2c/pdftex/pdflatex.fmt installed.
mktexfmt [INFO]: Successfully rebuilt formats: 1
mktexfmt [INFO]: Not selected formats: 26
mktexfmt [INFO]: Total formats: 27
mktexfmt [INFO]: exiting with status 0

error: plotimages: Failed to run pdflatex on <extended.pdf>
error: called from
    plotimages at line 105 column 9
make[2]: *** [Makefile:31286: doc/interpreter/extended.pdf] Error 1
make[2]: Leaving directory '/home/buildbotu/fc25-x86_64/gcc-fedora/build'
make[1]: *** [Makefile:27427: all-recursive] Error 1
make[1]: Leaving directory '/home/buildbotu/fc25-x86_64/gcc-fedora/build'
make: *** [Makefile:11059: all] Error 2

pdflate.log is attached -- I do not see anything wrong there either.

Dmitri.

(file #47804)

Dmitri A. Sergatskov <dasergatskov>
Mon 04 Nov 2019 11:45:07 PM UTC, comment #61: 

I wonder if this is ghostscript 9.50 getting more strict about it than 9.27.

Try this link:

https://web.archive.org/web/20170818010030/http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/postscript/pdfs/5002.EPSF_Spec.pdf

(This is Adobe's eps spec file)

I do not know what to do about it. 

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 04 Nov 2019 11:34:51 PM UTC, comment #60: 

Is there something we can do about this?

PS: The link doesn't work for me.

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 11:10:53 PM UTC, comment #59: 

The eps file has an illegal operator "setpagedevice"

See
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/postscript/pdfs/5002.EPSF_Spec.pdf (page 10)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 04 Nov 2019 10:56:33 PM UTC, comment #58: 

The single quotes was a red herring.
I commented the cleanup commands and can find the .eps file in the %temp% folder now (attached).

I then removed the --quiet switch from the epstool command and can see the following:

*** C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps:
epstool command: '"D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile="C:\Users\Markus\AppData\Local\Temp\oct-H4Vfne.eps" - & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-H4Vfne.eps "C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps" '
opengl-pipeline: '"D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile="C:\Users\Markus\AppData\Local\Temp\oct-H4Vfne.eps" - & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-H4Vfne.eps "C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps" '
"gswin32c.exe"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "c:\users\markus\appdata\local\temp\gsviewa13708"
Ghostscript failed to obtain bounding box
Failed

(file #47803)

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 10:39:18 PM UTC, comment #57: 

Sorry, I was copying from the wrong file. Here the actual output:

*** C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps:
epstool command: '"D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile="C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps" - & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --quiet --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps 'C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps'  & del "C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps" '
opengl-pipeline: '"D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile="C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps" - & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --quiet --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps 'C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps'  & del "C:\Users\Markus\AppData\Local\Temp\oct-Ucn8YY.eps" '

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 10:31:01 PM UTC, comment #56: 

I only run test 4 of your file and get the following output after applying your change:

*** C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps:
epstool command: 'cat > C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --quiet --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps 'C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps'  & del "C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps" '
opengl-pipeline: 'cat > C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps & "D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\epstool.exe" --quiet --copy --bbox C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps 'C:\Users\Markus\AppData\Local\Temp\print_test\4-eps.eps'  & del "C:\Users\Markus\AppData\Local\Temp\oct-IRzo5o.eps" '

But still no file.
Maybe an issue with single quotes and double quotes sometimes not being interchangeable on the Windows command line?

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 09:14:05 PM UTC, comment #55: 

@Markus: Ok, so the explanation is just above. We use ghostscript as an intermediate to write the gl2ps inputstream to an eps file:

  ## As epstool does not work with pipes, a subshell is used to
  ## permit piping.  Since this solution does not work with the DOS
  ## command shell, the -tight and -preview options are disabled if
  ## output must be piped.

  ## DOS Shell:
  ##   gs.exe [...] -sOutputFile=<filein> - & epstool -bbox -preview-tiff <filein> <fileout> & del <filein>

The following change will remove the spurious temporary file name. Does it fix the eps outputs?

diff -r 2f38c2681b3e scripts/plot/util/print.m
--- a/scripts/plot/util/print.m Mon Nov 04 12:22:23 2019 -0800
+++ b/scripts/plot/util/print.m Mon Nov 04 22:08:39 2019 +0100
@@ -889,7 +889,7 @@
                                   "device", epsdevice,
                                   "source", "-",
                                   "output", filein);
-        cmd = sprintf ("%s %s & %s", gs_cmd, filein, cmd);
+        cmd = sprintf ("%s & %s", gs_cmd, cmd);
       else
         cmd = sprintf ("cat > %s ; %s", filein, cmd);
       endif

Pantxo Diribarne <pantxo>
Project Member
Mon 04 Nov 2019 09:01:02 PM UTC, comment #54: 

Thanks.
The Fedora buildbots are still failing. I don't know whether this is the same error that they have more or less frequently for a while now - or whether it is something new.
The Debian buildbots seem to be happy now again.

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 08:28:16 PM UTC, comment #53: 

Yes, I tested that exact change with "DISPLAY= make all" to force the build to use Gnuplot, and it fixed the build error for me.

Pushed on the default branch

https://hg.savannah.gnu.org/hgweb/octave/rev/2f38c2681b3e

Mike Miller <mtmiller>
Project Administrator
Mon 04 Nov 2019 08:13:22 PM UTC, comment #52: 

You're right. It should probably have been this:

diff -r 688e8fb3caa9 scripts/plot/util/private/__ghostscript__.m
--- a/scripts/plot/util/private/__ghostscript__.m        Mon Nov 04 14:26:11 2019 -0500
+++ b/scripts/plot/util/private/__ghostscript__.m        Mon Nov 04 21:10:46 2019 +0100
@@ -126,7 +126,7 @@
       if (dos_shell)
         cleanup_cmd = sprintf ('del "%s"', strrep (offsetfile, '/', '\'));
       else
-        cleanup_cmd = sprintf ('rm "%s"', strrep (offsetfile, '/', '\'));
+        cleanup_cmd = sprintf ('rm "%s"', offsetfile);
       endif
     endif
     unwind_protect

Strangely, it doesn't cause an error for me though. But there are temporary files that aren't deleted.
@Mike: Could you please try with the above change or something similar?

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 07:38:00 PM UTC, comment #51: 

Just reading the diff, maybe this change was a mistake?

https://hg.savannah.gnu.org/hgweb/octave/rev/df8942d19b7b#l2.10

Mike Miller <mtmiller>
Project Administrator
Mon 04 Nov 2019 07:35:11 PM UTC, comment #50: 

I'm seeing some regressions in a build on Ubuntu, and I think it may be due to the change made here so far.

From the build log:

  GEN      doc/interpreter/convhull.pdf
  GEN      doc/interpreter/delaunay.pdf
rm: cannot remove '\tmp\oct-J0oeYT.ps': No such file or directory
---------- output begin ----------

----------- output end -----------
error: print: failed to print
error: called from
    __gnuplot_print__ at line 207 column 7
    print at line 731 column 14
    geometryimages at line 56 column 5
rm: cannot remove '\tmp\oct-kdXHre.ps': No such file or directory
---------- output begin ----------

----------- output end -----------
error: print: failed to print
error: called from
    __gnuplot_print__ at line 207 column 7
    print at line 731 column 14
    geometryimages at line 63 column 5
make[2]: *** [doc/interpreter/triplot.pdf] Error 1
make[2]: *** Waiting for unfinished jobs....
Makefile:27848: recipe for target 'doc/interpreter/triplot.pdf' failed
Makefile:27846: recipe for target 'doc/interpreter/voronoi.pdf' failed
make[2]: *** [doc/interpreter/voronoi.pdf] Error 1
rm: cannot remove '\tmp\oct-DOjm69.ps': No such file or directory

and so on.

This is a build on a headless system, so it is using Gnuplot to build the images in the doc/interpreter directory.

Mike Miller <mtmiller>
Project Administrator
Mon 04 Nov 2019 07:33:53 PM UTC, comment #49: 

There is this piece of code at around line 885 in print.m (function epstool) that selects ghostscript effectively for Windows (dos_shell). It is also where the temporary file (filein) is appended again to the ghostscript command.

    if (pipein)
      if (dos_shell)
        filein(filein=="'") = '"';
        gs_cmd = __ghostscript__ ("binary", opts.ghostscript.binary,
                                  "device", epsdevice,
                                  "source", "-",
                                  "output", filein);
        cmd = sprintf ("%s %s & %s", gs_cmd, filein, cmd);
      else
        cmd = sprintf ("cat > %s ; %s", filein, cmd);
      endif
    endif

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 04:11:56 PM UTC, comment #48: 

@Markus: At first sight I see that the temporary file appears twice in the call to gs, e.g. "5-epsc.eps":

opengl-pipeline: '"D:\Repositories\Octave\test\octave-2019-11-02-17-58-w64_kpse (test)\octave-2019-11-02-17-58-w64\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile="C:\Users\Markus\AppData\Local\Temp\oct-DgqgaQ.eps" - C:\Users\Markus\AppData\Local\Temp\oct-DgqgaQ.eps & ...

The latest instance of "C:\Users\Markus\AppData\Local\Temp\oct-DgqgaQ.eps" should not be here. But in the first place we should not need to use gs (on linux we directly "cat" the gl2ps output to epstool when we need to crop the file).

Pantxo Diribarne <pantxo>
Project Member
Mon 04 Nov 2019 03:43:19 PM UTC, comment #47: 

@Pantxo: No worries. And thank you for having done the hard lifting. I only had to polish the rough edges.
I'd still like to know why I am not able to print eps or epsc. Maybe it is related to the fact that short file names are disabled for the disc on which I usually test Octave.
Can you see something in the diary (cases 4 and 5) that seems odd to you?

Markus Mützel <mmuetzel>
Project Member
Mon 04 Nov 2019 03:37:21 PM UTC, comment #46: 

@Markus: many thanks for taking this on and testing.

@John: my apologies for the long standby. I guess I had gotten frustrated by the yoyo testing process, even though you replied very fast.

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Nov 2019 07:11:21 PM UTC, comment #45: 

Since there didn't seem to be any regressions, I pushed the change here:
http://hg.savannah.gnu.org/hgweb/octave/rev/df8942d19b7b

Markus Mützel <mmuetzel>
Project Member
Sun 03 Nov 2019 06:21:55 PM UTC, comment #44: 

I took the liberty to use Pantxo's patch and try it on a recent dev (1c13a0f36160).
The hunk that changed popen on Windows led to problems. So I reverted it and added the quotes in the pipeline instead.
Some paths were quoted twice. That doesn't seem to work.
Also some strings were used more than once as the format argument for sprintf. That lead to problems with "\" as the file separator.
After fixing those, almost all output formats in Pantxo's test print fine when Octave is installed in a path with spaces and parenthesis. The only ones failing are "eps" and "epsc".

An updated patch and the diary are attached.

Fwiw: "eps" and "epsc" didn't print for me before the changes either.

(file #47791, file #47792)

Markus Mützel <mmuetzel>
Project Member
Thu 26 Sep 2019 03:24:33 PM UTC, comment #43: 

I did a commit https://hg.octave.org/mxe-octave/rev/e640a2d2ede0 that prevents the user from using bad destination paths in the installer.

It wont stop anyone using the tarball instead

John Donoghue <lostbard>
Project Member
Wed 18 Sep 2019 12:25:03 PM UTC, comment #42: 

Other characters in the path that make the test plot script fail tests include:

^ & %

So it may still be easiest to check for the other chatacters and warn not to use them.

John Donoghue <lostbard>
Project Member
Thu 12 Sep 2019 12:21:31 PM UTC, comment #41: 

As another realted to ellipses in the path, looks  like most packages etc will fail building as include paths etc will contain the unescaped ()'s in the include paths etc, which bash will then complain about

John Donoghue <lostbard>
Project Member
Fri 06 Sep 2019 07:16:52 AM UTC, comment #40: 

(Pantxo here, unable to connect) Thanks. So "system" uses two different code path depending on whether an output value is requested or not. When an output value is requested "system" ends up using octave::popen, which I have modified to include surrounding quotes on Windows ... hence the spurious additional quotes in the error message. I'll modify the patch.

Anonymous
Thu 05 Sep 2019 12:22:49 PM UTC, comment #39: 

for test 4, 5, re comment #37, the call to epstool:

[status, devlist] = system (sprintf ('"%s" -h', opts.ghostscript.binary));

debug> opts.ghostscript.binary
ans = C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe
debug> sprintf ('"%s" -h', opts.ghostscript.binary)
ans = "C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe" -h
debug> [status, devlist] = system (sprintf ('"%s" -h', opts.ghostscript.binary));
'""C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe" -h"' is not recognized as an internal or external command,
operable program or batch file.
debug> status
status =  1
debug> devlist
devlist =
debug> system (sprintf ('"%s" -h', opts.ghostscript.binary));
GPL Ghostscript 9.27 (2019-04-04)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE           no pause after page   | -q       `quiet', fewer messages
-g<width>x<height>  page size in pixels   | -r<res>  pixels/inch resolution
-sDEVICE=<devname>  select device         | -dBATCH  exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
                                         embed %d or %ld for page #

So when calling with the out parameters, it fails, but not otherwise

John Donoghue <lostbard>
Project Member
Tue 03 Sep 2019 03:36:20 PM UTC, comment #38: 

Using current patch on stable, fails are 14, 15:

opengl-pipeline: '"C:OctaveOCTAVE~1.3)mingw64libexecoctave.1.1exec�_64-w64-mingw32octave-svgconvert.exe" - pdf 77.33 "C
:OctaveOCTAVE~1.3)mingw64shareoctave.1.1 ontsFreeSans.otf" 1 "C:\Users\JOHN\AppData\Local\Temp\oct-TbWC3q" & "C
:OctaveOCTAVE~1.3)mingw6inpstoedit.exe" -ssp -f fig "C:\Users\JOHNE\AppData\Local\Temp\oct-TbWC3q" 2> NUL | "C:\O
ctave\OCTAVE~1.3)\mingw64\bin\fig2dev.exe" -L emf 2> NUL > "C:\Users\JOHN\AppData\Local\Temp\print_test\15-meta.
emf"'
The filename, directory name, or volume label syntax is incorrect.
warning: print.m: No such file or directory, 'C:\Users\JOHN\AppData\Local\Temp\oct-TbWC3q'

And then 4, 5 with the 'Unknown device: epswrite'

Debugging test 15, the escaping getting messed up occurs at line
110 of _opengl_print_.m:

        cmd_pstoedit = sprintf (opts.pstoedit_cmd (opts, "fig"), ...
                                "pdf", tmp, tmp);

opts.pstoedit_cmd(opts, "fig") returns:

"C:\Octave\OCTAVE~1.3)\mingw64\libexec\octave\5.1.1\exec\x86_64-w64-mingw32\octave-svgconvert.exe" - %s 77.33 "C:\Octave\OCTAVE~1.3)
\mingw64\share\octave\5.1.1\fonts\FreeSans.otf" 1 "%s" & "C:\Octave\OCTAVE~1.3)\mingw64\bin\pstoedit.exe" -ssp -f fig "%s" 2> NUL

but cmd_pstoedit returns as :

"C:OctaveOCTAVE~1.3)mingw64libexecoctave.1.1exec�_64-w64-mingw32octave-svgconvert.exe" - pdf 77.33 "C:OctaveOCTAVE~1.3)mingw64shareoctave
.1.1 ontsFreeSans.otf" 1 "C:\Users\JOHN\AppData\Local\Temp\oct-K0IzPW" & "C:OctaveOCTAVE~1.3)mingw6inpstoedit.exe" -ssp -f fig "C
:\Users\JOHN\Local\Temp\oct-K0IzPW" 2> NUL

For test 4, after line 881:

fileout(fileout=="'") = '"';

so:
fileout = "C:\Users\JDONOG~1.ECE\AppData\Local\Temp\toto.eps"

_ghostscript_.m, line 154:

   cmd = sprintf ('"%s" %s -sOutputFile="%s"',
                   opts.binary, gs_opts, opts.output);

cmd = "C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=epswrite -sOutputFile=
""C:\Users\JDONOG~1.ECE\AppData\Local\Temp\toto.eps""

opts.binary = C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe

opts.output = "C:\Users\JOHN\AppData\Local\Temp\toto.eps"

opts.source = -

Line 182:

cmd = sprintf ("%s %s", cmd, opts.source);

cmd = "C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=epswrite -sOutputFile=
""C:\Users\JOHN\AppData\Local\Temp\toto.eps"" -

_opengl_print_.m, line 203:

drawnow (gl2ps_device{n}, ['|' pipeline{n}]);

input:

gl2ps_device{n} = eps

pipeline{n} = "C:\Octave\OCTAVE~1.3)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None  sDEVICE=epswrite -sOutputFile=
""C:\Users\JOHN\AppData\Local\Temp\toto.eps"" -

Then the unknown device epswrite

If I do a system(pipeline{n})

I get the same unknown device epswrite

John Donoghue <lostbard>
Project Member
Mon 02 Sep 2019 07:29:22 PM UTC, comment #37: 

@John: Thank you. The attached patch should fix 14, 15, 16, but for eps formats I am a bit lost.

I know nothing about "8.3 path". Does the path in the error message reproduced below look like a valid path?

'""C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -h"' is not recognized as an internal or external command

This command is run using "system" in print>epstool at line 808, could you try to understand why it fails, and why we see those strange additional surrounding double quotes:

dbstop print>epstool 808
plot (1:10)
print ("-debug", fullfile (tempdir (), "toto.eps"))

BTW, "eps2write" is part of any recent ghostscript version, so the easiest fix for this bug is to simply not run this command and use "eps2write" by default (as done on linux).

(file #47441)

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Aug 2019 01:12:22 PM UTC, comment #36: 

For references, gs -h itself returns the following devices i the windows build:

Available devices:
   ap3250 atx23 atx24 atx38 bbox bit bitcmyk bitrgb bitrgbtags bj10e bj200
   bjc600 bjc800 bmp16 bmp16m bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8
   ccr cdeskjet cdj500 cdj550 cdjcolor cdjmono cfax cif cljet5 cljet5c
   cljet5pr coslw2p coslwxl declj250 deskjet devicen dfaxhigh dfaxlow
   display dj505j djet500 djet500c dnj650c eps2write eps9high eps9mid epson
   epsonc escp faxg3 faxg32d faxg4 fpng fs600 gprf hl7x0 ibmpro imagen
   inferno ink_cov inkcov itk24i itk38 jetp3852 jpeg jpegcmyk jpeggray
   laserjet lbp8 lips3 lj250 lj3100sw lj4dith lj4dithp lj5gray lj5mono
   ljet2p ljet3 ljet3d ljet4 ljet4d ljet4pjl ljetplus lp2563 lp8000 lq850
   lxm5700m m8510 mgr4 mgr8 mgrgray2 mgrgray4 mgrgray8 mgrmono miff24 necp6
   nullpage oce9050 oki182 okiibm paintjet pam pamcmyk32 pamcmyk4 pbm pbmraw
   pclm pcx16 pcx24b pcx256 pcxcmyk pcxgray pcxmono pdfimage24 pdfimage32
   pdfimage8 pdfwrite pdfwrite pdfwrite pgm pgmraw pgnm pgnmraw photoex
   picty180 pj pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw plan plan9bm
   planc plang plank planm plib plibc plibg plibk plibm png16 png16m png256
   png48 pngalpha pnggray pngmono pngmonod pnm pnmraw ppm ppmraw ps2write
   psdcmyk psdcmyk16 psdcmykog psdrgb psdrgb16 pxlcolor pxlmono r4081 rinkj
   sj48 spotcmyk st800 stcolor t4693d2 t4693d4 t4693d8 tek4696 tiff12nc
   tiff24nc tiff32nc tiff48nc tiff64nc tiffcrle tiffg3 tiffg32d tiffg4
   tiffgray tifflzw tiffpack tiffscaled tiffscaled24 tiffscaled32
   tiffscaled4 tiffscaled8 tiffsep tiffsep1 txtwrite uniprint xcf xpswrite

John Donoghue <lostbard>
Project Member
Thu 29 Aug 2019 01:09:19 PM UTC, comment #35: 

Test 4 and 5 fail still:

fname = C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps
*** C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps:
'""C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -h"' is not recognized as an internal or external command,
operable program or batch file.
epstool command: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVI
CE=epswrite -sOutputFile=""C:\Users\JDONOG~1.ECE\AppData\Local\Temp\print_test\4-eps.eps"" -'
opengl-pipeline: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVI
CE=epswrite -sOutputFile=""C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps"" -'
Unknown device: epswrite


fname = C:\Users\JOHN\AppData\Local\Temp\print_test\5-epsc.eps
*** C:\Users\JOHN\AppData\Local\Temp\print_test\5-epsc.eps:
epstool command: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVI
CE=epswrite -sOutputFile=""C:\Users\JOHN\AppData\Local\Temp\print_test\5-epsc.eps"" -'
opengl-pipeline: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVI
CE=epswrite -sOutputFile=""C:\Users\JOHN\AppData\Local\Temp\print_test\5-epsc.eps"" -'
Unknown device: epswrite

Test 14, 15 and 16 fail:

fname = C:\Users\JOHN\AppData\Local\Temp\print_test\14-emf.emf
*** C:\Users\JOHN\AppData\Local\Temp\print_test\14-emf.emf:
fig2dev command: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\fig2dev.exe" -L emf 2> NUL'
svgconvert command: '"C:\Octave\OCTAVE~1.X)\mingw64\libexec\octave\5.1.1\exec\x86_64-w64-mingw32\octave-svgconvert.exe"
- %s 77.33 "C:\Octave\OCTAVE~1.X)\mingw64\share\octave\5.1.1\fonts\FreeSans.otf" 1 "%s"'
pstoedit command: '""C:\Octave\OCTAVE~1.X)\mingw64\libexec\octave\5.1.1\exec\x86_64-w64-mingw32\octave-svgconvert.exe" -
%s 77.33 "C:\Octave\OCTAVE~1.X)\mingw64\share\octave\5.1.1\fonts\FreeSans.otf" 1 "%s"" & C:\Octave\OCTAVE~1.X)\mingw64\
bin\pstoedit.exe -ssp -f fig "%s" 2> NUL'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\m' -- converting to 'm'
warning: unrecognized escape sequence '\l' -- converting to 'l'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\e' -- converting to 'e'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\m' -- converting to 'm'
warning: unrecognized escape sequence '\s' -- converting to 's'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\F' -- converting to 'F'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\m' -- converting to 'm'
warning: unrecognized escape sequence '\p' -- converting to 'p'
opengl-pipeline: '""C:OctaveOCTAVE~1.X)mingw64libexecoctave.1.1exec�_64-w64-mingw32octave-svgconvert.exe" - pdf 77.33 "
C:OctaveOCTAVE~1.X)mingw64shareoctave.1.1 ontsFreeSans.otf" 1 "C:\Users\JOHN\AppData\Local\Temp\oct-gyLwhD"" &
C:OctaveOCTAVE~1.X)mingw6inpstoedit.exe -ssp -f fig "C:\Users\JOHN\AppData\Local\Temp\oct-gyLwhD" 2> NUL | "C:\O
ctave\OCTAVE~1.X)\mingw64\bin\fig2dev.exe" -L emf 2> NUL > "C:\Users\JOHN\AppData\Local\Temp\print_test\14-emf.e
mf"'
The filename, directory name, or volume label syntax is incorrect.
warning: print.m: No such file or directory, 'C:\Users\JOHN\AppData\Local\Temp\oct-gyLwhD'

John Donoghue <lostbard>
Project Member
Wed 28 Aug 2019 09:27:12 PM UTC, comment #34: 

Yes, mine too, but there is no "epswrite"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Aug 2019 08:52:44 PM UTC, comment #33: 

@John: Thank you. I think the two following changes (m files only) should help:

--- a/scripts/plot/util/print.m Tue Aug 27 22:51:03 2019 +0200
+++ b/scripts/plot/util/print.m Wed Aug 28 22:40:13 2019 +0200
@@ -805,7 +805,7 @@
              "print: 'gs' (Ghostscript) is required for specified output format, but binary is not available in PATH");
     endif

-    [status, devlist] = system (sprintf ("%s -h", opts.ghostscript.binary));
+    [status, devlist] = system (sprintf ('"%s" -h', opts.ghostscript.binary));
     if (isempty (strfind (devlist, "eps2write")))
       epsdevice = "epswrite";
     else
diff -r 996229be0045 scripts/plot/util/private/__opengl_print__.m
--- a/scripts/plot/util/private/__opengl_print__.m      Tue Aug 27 22:51:03 2019 +0200
+++ b/scripts/plot/util/private/__opengl_print__.m      Wed Aug 28 22:40:13 2019 +0200
@@ -83,7 +83,7 @@
         svgcmd = opts.svgconvert_cmd (opts, opts.ghostscript.device);
       endif
       if (! isempty (svgcmd))
-        pipeline = {sprintf(svgcmd, "svg", opts.name)};
+        pipeline = {sprintf(undo_string_escapes  (svgcmd), "svg", opts.name)};
       else
         pipeline = {sprintf('cat > "%s"', opts.name)};
       endif
@@ -137,7 +137,7 @@
         tmp = tempname ();
         opts.ghostscript.source = tmp;
         opts.unlink = [opts.unlink tmp];
-        svgcmd = sprintf (svgcmd, "pdf", tmp);
+        svgcmd = sprintf (undo_string_escapes  (svgcmd), "pdf", tmp);
       endif

I attached the corresponding updated patch.

@Dmitri: My version of ghostscript does have both ps2write and eps2write.

(file #47405)

Pantxo Diribarne <pantxo>
Project Member
Wed 28 Aug 2019 05:54:20 PM UTC, comment #32: 

At least on my ghostscript (Fedora), the device name is "eps2write".

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Aug 2019 05:45:28 PM UTC, comment #31: 

Patching stable

The test from comment #23 appears to work with the latest patch.

Running the test script, I get a number of failures for some of the types:

basedir = C:\Users\JOHN\AppData\Local\Temp\print_test
diaryfile = C:\Users\JOHN\AppData\Local\Temp\print_test\print_diary.txt
*** C:\Users\JOHN\AppData\Local\Temp\print_test\1-svg.svg:
svgconvert command: '"C:\Octave\OCTAVE~1.X)\mingw64\libexec\octave\5.1.1\exec\x86_64-w64-mingw32\octave-svgconvert.exe"
- %s 77.33 "C:\Octave\OCTAVE~1.X)\mingw64\share\octave\5.1.1\fonts\FreeSans.otf" 1 "%s"'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\m' -- converting to 'm'
warning: unrecognized escape sequence '\l' -- converting to 'l'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\e' -- converting to 'e'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\O' -- converting to 'O'
warning: unrecognized escape sequence '\m' -- converting to 'm'
warning: unrecognized escape sequence '\s' -- converting to 's'
warning: unrecognized escape sequence '\o' -- converting to 'o'
warning: unrecognized escape sequence '\F' -- converting to 'F'
opengl-pipeline: '"C:OctaveOCTAVE~1.X)mingw64libexecoctave.1.1exec�_64-w64-mingw32octave-svgconvert.exe" - svg 77.33 "C
:OctaveOCTAVE~1.X)mingw64shareoctave.1.1 ontsFreeSans.otf" 1 "C:\Users\JOHN\AppData\Local\Temp\print_test\1-svg
.svg"'
The filename, directory name, or volume label syntax is incorrect.

Same issue is seen for 14-emf.emf, 15-meta.emf, 16-fig.fig

Next set of issues:

*** C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps:
'"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe -h"' is not recognized as an internal or external command,
operable program or batch file.
epstool command: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -
sDEVICE=epswrite -sOutputFile=""C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps"" -'
opengl-pipeline: '"C:\Octave\OCTAVE~1.X)\mingw64\bin\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -
sDEVICE=epswrite -sOutputFile=""C:\Users\JOHN\AppData\Local\Temp\print_test\4-eps.eps"" -'
Unknown device: epswrite

Same error for 5-epsc.eps

John Donoghue <lostbard>
Project Member
Tue 27 Aug 2019 09:20:51 PM UTC, comment #30: 

I attached an updated patch in which I took care of quoting binary and output file names. I also attached a script (print_coverage.m) that should be run using the qt toolkit to test most output formats and print the command pipelines to a diary file "coverage.txt".

Could some of you try to patch Octave, install it in a directory with parenthesis, run the script and then report back attaching the diary file?

(file #47400, file #47401)

Pantxo Diribarne <pantxo>
Project Member
Sun 25 Aug 2019 04:27:45 PM UTC, comment #29: 

@John, Philip: Thank you both. I had assumed binary names were already quoted (misinterpreted comment #17). I'll rework the patch to make sure all binary names and file names are quoted.

Changing item group to "Unexpected Error" since this doesn't cause a crash anymore (exceptions in the GUI are now caught and rethrown to the interpreter, hence this strange "Parse Error").

Pantxo Diribarne <pantxo>
Project Member
Fri 23 Aug 2019 06:01:40 PM UTC, comment #28: 

Some energy provider mechanic didn't show up today :-( up so I could proceed (there's always a sunny side isn't it).

With Panxto's patch from comment #23 I get this:

>> plot (1:10)
>> print (fullfile (tempdir, "toto.pdf"))
'C:\PROGRA~1\Octave\OCTAVE~1.0_' is not recognized as an internal or external command,
operable program or batch file.
error: gl2ps_renderer::draw: internal pipe error
>>

and

>> OCTAVE_HOME
ans = C:\PROGRA~1\Octave\OCTAVE~1.0_(\mingw64

... but not really, it is

C:\Program Files\Octave\Octave-6.0.0_(bug45718)

so apparently the parenthesis is still a problem, confirming what I see in comment #27.

(BTW I always figured that OCTAVE HOME would be the installation subdirectory but it is mingw64/ inside it, is seems. Apparently it's like that since the change to MSYS2).

Anyway, I usually install my Octave crossbuilds into
C:\Programs\Octave\Octave-version_date\
and with one of those installations (w/o patch of comment #23) the example in comment #23 works fine.

My conclusion:
Octave itself works fine if installed in a path with spaces in the subdir names, but it's still not totally immune to spaces.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 23 Aug 2019 12:13:03 PM UTC, comment #27: 

Using c:\octave\Octave(5.1.1):

Even without the patch, it doesnt crash for me since the change to mxe to use 8.3 paths.

https://hg.octave.org/mxe-octave/rev/a45374f7d9a3

If I dont use the 3.8 path, I dont get a crash but:

>> plot (1:10)

>> print (fullfile (tempdir, "toto.pdf"))

'C:\Octave\Octave' is not recognized as an internal or external command,
operable program or batch file.
error: gl2ps_renderer::draw: internal pipe error
>> error: parse error
error: called from
    __opengl_print__ at line 202 column 7
    print at line 710 column 16
>>

Note sure if the change is due since 2016 to updates to glps, ghostscript, the fact we use  msys2 ...

With the patch applied, works ok with 8.3 path.

Without 8.3 path:

>> print (fullfile (tempdir, "toto.pdf"))

'C:\Octave\Octave' is not recognized as an internal or external command,
operable program or batch file.
error: gl2ps_renderer::draw: internal pipe error
>> error: parse error
error: called from
    __opengl_print__ at line 202 column 7
    print at line 710 column 16
>>

Looking at line 202 of _opengl_print_.m, (in the patched octave) if I add:

        ## Use toolkits "print_figure" method
      + printf("printing to '%s' with '%s'\n", gl2ps_device{n}, pipeline{n});
        drawnow (gl2ps_device{n}, ['|' pipeline{n}]);

Running again, it prints out:

printing to 'eps' with 'C:\Octave\Octave(5.1.1.22)\mingw64\bin\gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -dA
utoRotatePages=/None -sDEVICE=pdfwrite -dLanguageLevel=2 -dEmbedAllFonts=true -dOptimize=true -sPAPERSIZE=l
etter -dFIXEDMEDIA -sOutputFile="C:\Users\JOHN\AppData\Local\Temp\toto.pdf" C:\Users\JOHN\A
ppData\Local\Temp\oct-fDP6w8.ps - & del C:\Users\JOHN\AppData\Local\Temp\oct-fDP6w8.ps'

John Donoghue <lostbard>
Project Member
Fri 23 Aug 2019 12:09:16 PM UTC, comment #26: 

@Philip: Thanks. Can you install octave in a directory with parenthesis, e.g. "C:\Program_Files_(x86)"? According to comment #4 this causes the same problems.

Anonymous
Fri 23 Aug 2019 11:45:40 AM UTC, comment #25: 

I've beaten myself ;-) (found a spell to get it built).

But no joy yet, Octave refuses to be installed, it pops up a message:
"Octave should not be installed to a destination folder containing spaces. Please select another destination".
I knew about this but always thought it could be overridden; but alas, no.

Apart from the exact semantics (folders usually contain files or other folders, not spaces) this is a bit unhelpful.

I know where to look (in tools/make_installscript.sh) but that is out of reach ATM, I have to do other things now.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 23 Aug 2019 07:55:29 AM UTC, comment #24: 

I can try but only next week. Maybe someone beats me to it.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 22 Aug 2019 09:03:21 PM UTC, comment #23: 

Could someone, with an MXE setup, build with the attached patch, install Octave in a directory with space and/or parenthesis, and try to print?

plot (1:10)
print (fullfile (tempdir, "toto.pdf"))
## Parenthesis in file path
basedir = fullfile (tempdir, "path with spaces");
mkdir (basedir);
print (fullfile (basedir, "toto.pdf"))

If this doesn't work, does Octave still crash or does it throw an error?

(file #47381)

Pantxo Diribarne <pantxo>
Project Member
Sat 13 Apr 2019 09:06:13 PM UTC, comment #22: 

The ideas in the following post look interesting:

https://stackoverflow.com/questions/9964865/c-system-not-working-when-there-are-spaces-in-two-different-parameters

In short when cmd.exe (I assume this is what is behind pipes as for system calls) finds parents or special characters, the first and last quotes are removed. So we should surround the executable name and file names with quotes, as we currently do, but also the whole command before passing it to a pipe.

If I understand correctly we should do system calls this way:

system ("\"\"PATH_WITH_PARENTS_AND_SPACES\prog.exe" nospaces \"text with spaces\"\"");

This may solve the issue with both space and parents.

Pantxo Diribarne <pantxo>
Project Member
Tue 06 Mar 2018 01:43:14 PM UTC, comment #21: 

Could someone able to reproduce the original bug try with the current dev version? I hope this will now lead to an error instead of a segfault (we now rethrow exceptions from the GUI thread to the interpreter thread).

Pantxo Diribarne <pantxo>
Project Member
Thu 08 Dec 2016 01:37:09 PM UTC, comment #20: 

Not that it fixes issues with running programs external to the mxe-octave paths, but what happens if we use the shortpath name instead for the octave path ?

Ie: adding to OctavePath section of octave.vbs:

OctavePath = fso.GetParentFolderName(WScript.ScriptFullName)
Set fo = fso.GetFolder(OctavePath)
OctavePath = fo.ShortPath

John Donoghue <lostbard>
Project Member
Fri 02 Dec 2016 10:22:54 AM UTC, comment #19: 

octave_popen eventually resolves to calls in sysdep.cc.

FILE *
octave_popen (const char *command, const char *mode)
{
#if defined (__MINGW32__) || defined (_MSC_VER)
  if (mode && mode[0] && ! mode[1])
    {
      char tmode[3];
      tmode[0] = mode[0];
      tmode[1] = 'b';
      tmode[2] = 0;

      return _popen (command, tmode);
    }
  else
    return _popen (command, mode);
#else
  return popen (command, mode);
#endif
}

Since we are using different code on different systems, it is possible that _popen on Windows does not handle spaces well, while the popen command on Linux has no issues.

Rik <rik5>
Project Administrator
Fri 02 Dec 2016 10:20:20 AM UTC, comment #18: 

I had a similar problem here with space characters:
https://savannah.gnu.org/bugs/?43534
"Octave shouldn't be installed in a path containing spaces. Just live with it."
(Here again in comment #3)

The fix was to prohibit space characters in the path which is checked at install time under Windows (when using the installer).
(Here again in comment #8)

Now there are other exemptions like parenthesis (#49718), German Umlaut-characters (#42036), French accents (#40239), Japanese characters (#44922) etc., ending in a common subset for POSIX portable filename characters.

Personally, I'm not happy with this. Whatever the operating system is allowing should be allowed, too.

At the end, there should IMHO be a clear design decision, either:

  • Octave accepts anything legal on the underlying OS for paths, installation folder, working folder, *.m file names, etc. (in every aspect of program usage)
  • Octave sticks to the lowest common denominator, the character set of POSIX "Fully portable filenames"

Anything in between might lead to an infinite loop with repeated, slightly deviating bug reports.

Armin Müller <arm_in>
Fri 02 Dec 2016 12:07:17 AM UTC, comment #17: 

I put gs.exe in the directory

c:\gs 2\

Using

debug_on_error (1)
plot (1:10)
print -deps junk.eps

I get

'c:\gs' is not recognized as an internal or external command,
operable program or batch file.
error: gl2ps_renderer::draw: internal pipe error
error: called from
    __opengl_print__ at line 169 column 7
    print at line 503 column 14
stopped in C:\Octave\Octave-4.2.0\share\octave\4.2.0\m\plot\util\private\__openg
l_print__.m at line 169
169:       drawnow (gl2ps_device{n}, ['|' pipeline{n}]);

Inspecting variables in the m-file, pipeline{n} is

"c:\gs 2\gs.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -
sDEVICE=eps2write -sOutputFile=""junk.eps"" -

print.m is trying to protect the command by placing it in double quotes, but this may not be enough.

Lookin in gl2ps_print.cc, there is only one place where the phrase "internal pipe error" occurs which is when Octave fails to read from the temporary file containing gl2ps output and write to the pipe created with octave_popen.

The code that opens the pipe is

// Create process and pipe gl2ps output to it.

std::string cmd = stream.substr (1);

fp = octave_popen (cmd.c_str (), "w");

if (! fp)
  error ("print: failed to open pipe \"%s\"", stream.c_str ());

frame.add_fcn (safe_pclose, fp);

So we check immediately to see if the pipe was created successfully.  Apparently, you can create the pipe but having any old command is fine because it doesn't really invoke it until something is written to the input side of the pipe.

The segfault is caused eventually by

if (nwrite != nread)
  {
    octave::signal_handler ();   // Clear SIGPIPE signal
    error ("gl2ps_renderer::draw: internal pipe error");
  }

This is a known problem.  Because we have different threads running, when error() is called it seems to not pick up our installed error handler and return to the Octave prompt.  Instead, it picks up the default which is exit().

Rik <rik5>
Project Administrator
Thu 01 Dec 2016 09:48:43 PM UTC, comment #16: 

Not sure of how much it is, when when it crashes, bt on mine:

Thread 1 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7712.0x3818]
0x01895571 in std::_Rb_tree<int, std::pair<int const, octave_value>, std::_Select1st<std::pair<int const, octave_value> >, std::less<int>, std::allocator<std::pair<int const, octave_value> > >::find (this=0x1f429068, __k=@0x60d17c: 80)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:1910
1910    /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h: No such file or directory.
(gdb) where
#0  0x01895571 in std::_Rb_tree<int, std::pair<int const, octave_value>, std::_Select1st<std::pair<int const, octave_value> >, std::less<int>, std::allocator<std::pair<int const, octave_value> > >::find (this=0x1f429068, __k=@0x60d17c: 80)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:1910
#1  0x011d8996 in std::map<int, octave_value, std::less<int>, std::allocator<std::pair<int const, octave_value> > >::find (__x=@0x60d17c: 80,
    this=0x1f429068) at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_map.h:860
#2  symbol_table::fcn_info::fcn_info_rep::erase_subfunction (scope=80, this=0x1f429060)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:828
#3  symbol_table::fcn_info::erase_subfunction (scope=80, this=0x1f44fa2c)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:1083
#4  symbol_table::erase_subfunctions_in_scope (scope=80)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:1236
#5  symbol_table::erase_scope (scope=80) at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:1219
#6  octave_user_function::~octave_user_function (this=this@entry=0x27916be0, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/octave-value/ov-usr-fcn.cc:225
#7  0x011d8beb in octave_user_function::~octave_user_function (this=0x27916be0, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/octave-value/ov-usr-fcn.cc:226
#8  0x0188ef12 in symbol_table::fcn_info::fcn_info_rep::~fcn_info_rep (this=0x273f33e0, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:752
#9  symbol_table::fcn_info::~fcn_info (this=0x279f410c, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.h:1014
#10 std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info>::~pair (this=0x279f4108,
    __in_chrg=<optimized out>) at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_pair.h:96
#11 __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info> > >::destroy<std::pair<std::basic_string<char> const, symbol_table::fcn_info> > (this=<optimized out>, __p=0x279f4108)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/ext/new_allocator.h:124
#12 std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info> > > >::destroy<std::pair<std::basic_string<char> const, symbol_table::fcn_info> > (__a=..., __p=0x279f4108)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/alloc_traits.h:539
#13 std::_Rb_tree<std::string, std::pair<std::string const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::string const, symbol_table::fcn_info> >, std::less<std::string>, std::allocator<std::pair<std::string const, symbol_table::fcn_info> > >::_M_destroy_node (
    this=0x1bafd78 <symbol_table::fcn_table>, __p=0x279f40f8)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:436
#14 std::_Rb_tree<std::string, std::pair<std::string const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::string const, symbol_table::fcn_info> >, std::less<std::string>, std::allocator<std::pair<std::string const, symbol_table::fcn_info> > >::_M_erase (
    this=this@entry=0x1bafd78 <symbol_table::fcn_table>, __x=0x279f40f8)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:1247
#15 0x0188eecf in std::_Rb_tree<std::string, std::pair<std::string const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::string const, symbol_table::fcn_info> >, std::less<std::string>, std::allocator<std::pair<std::string const, symbol_table::fcn_info> > >::_M_erase (
    this=this@entry=0x1bafd78 <symbol_table::fcn_table>, __x=0x2247e9d0)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:1245
#16 0x0188eecf in std::_Rb_tree<std::string, std::pair<std::string const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::string const, symbol_table::fcn_info> >, std::less<std::string>, std::allocator<std::pair<std::string const, symbol_table::fcn_info> > >::_M_erase (
    this=this@entry=0x1bafd78 <symbol_table::fcn_table>, __x=0x2247c8d0)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:1245
#17 0x016368a5 in std::_Rb_tree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info> > >::~_Rb_tree (this=0x1bafd78 <symbol_table::fcn_table>, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_tree.h:715
#18 std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, symbol_table::fcn_info, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::fcn_info> > >::~map (this=0x1bafd78 <symbol_table::fcn_table>, __in_chrg=<optimized out>)
    at /home/johnd/mxe-octave/build-qt4/usr/lib/gcc/i686-w64-mingw32/4.9.4/include/c++/bits/stl_map.h:96
#19 __tcf_6 () at /home/johnd/mxe-octave/build-qt4/tmp-stable-octave/octave-4.2.0/libinterp/corefcn/symtab.cc:62
#20 0x00db11b4 in _CRT_INIT@12 (hDllHandle=hDllHandle@entry=0xdb0000, dwReason=dwReason@entry=0, lpreserved=lpreserved@entry=0x1)
    at /home/johnd/mxe-octave/build-qt4/tmp-build-gcc/gcc-4.9.4/mingw-w64-v4.0.6/mingw-w64-crt/crt/crtdll.c:144
#21 0x00db1325 in __DllMainCRTStartup (hDllHandle=hDllHandle@entry=0xdb0000, dwReason=0, lpreserved=lpreserved@entry=0x1)
    at /home/johnd/mxe-octave/build-qt4/tmp-build-gcc/gcc-4.9.4/mingw-w64-v4.0.6/mingw-w64-crt/crt/crtdll.c:211
#22 0x00db1433 in DllMainCRTStartup@12 (hDllHandle=0xdb0000, dwReason=0, lpreserved=0x1)
    at /home/johnd/mxe-octave/build-qt4/tmp-build-gcc/gcc-4.9.4/mingw-w64-v4.0.6/mingw-w64-crt/crt/crtdll.c:171
#23 0x77166b8e in ntdll!RtlDecompressBuffer () from C:\WINDOWS\SYSTEM32\ntdll.dll
#24 0x77135ade in ntdll!RtlAnsiCharToUnicodeChar () from C:\WINDOWS\SYSTEM32\ntdll.dll
#25 0x77147efc in ntdll!LdrShutdownProcess () from C:\WINDOWS\SYSTEM32\ntdll.dll
#26 0x00000000 in ?? ()

John Donoghue <lostbard>
Project Member
Thu 01 Dec 2016 09:38:53 PM UTC, comment #15: 

moving gs.exe to a path with spaces in it and adding that path to octave causes octave to 'lockup' and/or crash for me.

John Donoghue <lostbard>
Project Member
Tue 29 Nov 2016 09:47:58 AM UTC, comment #14: 

@Rik, comment #12: there is no system call in gl2ps. When we need to postprocess the generated eps, we copy the content of gl2ps temporary FILE into a file stream (pipe) after gl2ps has returned.
The stream is created before the call to gl2ps using octave_popen.

So it may also be the call to octave_popen that is failing when the name of the targeted external executable contains parents.

Pantxo Diribarne <pantxo>
Project Member
Tue 29 Nov 2016 01:20:03 AM UTC, comment #13: 

According to comment #6, Octave crashes, fully exits and leaves behind an octave-workspace.

Btw, I did copy /usr/bin/epstool into "/tmp/Program Files (x86)/Octave/Octave-4.2.0/bin" and set PATH so that it would be called when I print to a .eps file. But still no crash here. I have not yet tried that with ghostscript.

Mike Miller <mtmiller>
Project Administrator
Tue 29 Nov 2016 01:15:20 AM UTC, comment #12: 

From what I remember about a similar bug report, the crash is hard and is something to do with gl2ps being the one to invoke the system command.

Rik <rik5>
Project Administrator
Tue 29 Nov 2016 01:09:52 AM UTC, comment #11: 

I agree with Mike that we should aim for being able to install in any directory as long as the name is a valid file name for the operating system.

As for why it could fail on Windows but not a GNU system, if it is a problem with an external dependency program like ghostcript, then my guess is that other program doesn't work properly when installed  But that's not the case on the GNU system, where the external program is installed in /usr/bin (or similar) even when you install Octave in a directory like

  ~/Program Files(x86)/whatever/...

Also, as Mike asked, what do we mean by "crash" here?  Does Octave exit?  Or does it just throw an error and fail to generate the desired output?

If Octave actually exits because of some external dependency that is doing the wrong thing, then we might still have a bug in Octave.  Or it would be nice to fix the dependency to not fail in a way that causes Octave to crash.

If it is an external program like ghostcript that causes the trouble, then I'd be surprised if Octave crashes because of it.  But if it is something like gl2ps that is linked with Octave, then I can see how it could easily cause Octave to exit with a segfault if it doesn't properly handle a non-portable filename.

John W. Eaton <jwe>
Project Administrator
Tue 29 Nov 2016 01:05:04 AM UTC, comment #10: 

We could do some testing, but I imagine any shell special character such as

[]()*?

are going to be a problem.

Long term, it might be good to follow Mike's suggestion and figure out if there is a way to quote the path before we pass it to the shell.

Rik <rik5>
Project Administrator
Tue 29 Nov 2016 12:57:56 AM UTC, comment #9: 

Checking for more characters and expanding the warning is probably sufficient to address this for now. I still think it would be a valid wishlist project for someone to work on. But I am unable to reproduce any of the problems described here in a directory containing spaces and parentheses on Debian. I have also copied the epstool binary into this private bin directory and set PATH appropriately, and still no problems.

If we want to be really stringent about the allowed characters, POSIX defines the set of portable filename characters as alphanumeric, period, underscore, and hyphen.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276

https://github.com/boostorg/filesystem/blob/develop/src/portability.cpp#L43

Mike Miller <mtmiller>
Project Administrator
Tue 29 Nov 2016 12:43:18 AM UTC, comment #8: 

For comment #7, Easy enough to add to the installer check. There are probally some other characters that should not be used as well

John Donoghue <lostbard>
Project Member
Mon 28 Nov 2016 10:12:22 PM UTC, comment #7: 

I'm adding John D. to the CC list since he does most of the work on the MXE installer.

There is a function for the Windows installer which checks for spaces in the name and alerts the user that this is a bad idea.  A simple partial solution would be to extend this function to check for other questionable characters and throw up the same dialog box.  The function is located in the MXE repository in the file tools/makeinst-script.sh.in.

The code itself is:

; Check whether prev install is here and no spaces in dest name
Function CheckPrevInstallAndDest
  IfFileExists "\$INSTDIR\\bin\\octave.exe" inst_exists  inst_none
inst_exists:
  MessageBox MB_YESNO|MB_ICONEXCLAMATION "Another Octave installation has been detected at that destination. It is recommended to uninstall it if you intend to use the same installation directory. Do you want to proceed with the installation anyway?" IDYES inst_none IDNO 0
  Abort
  GoTo inst_end
inst_none:


  ; check for spaces in dest filename
  Push \$R0
  Push \$R1

  StrCpy \$R1 0 # r1 = counter
space_loop:
  StrCpy \$R0 \$INSTDIR 1 \$R1  # R0 = character in string to check
  StrCmp \$R0 "" space_end # end of string
  StrCmp \$R0 " " space_found
  IntOp  \$R1 \$R1 + 1
  GoTo space_loop
space_found:
  MessageBox MB_OK|MB_ICONEXCLAMATION "Octave should not be installed to a destination folder containing spaces. Please select another destination."
  Abort
space_end:
  Pop \$R1
  Pop \$R0

inst_end:

FunctionEnd

Rik <rik5>
Project Administrator
Mon 28 Nov 2016 07:29:08 PM UTC, comment #6: 

I reinstalled Octave to C:\Program_Files_(x86)\Octave\Octave-4.2.0\ . Printing to an svg file did not cause Octave to crash. By crash I mean that Octave exits and produces the file octave-workspace to the working directory. Printing to an eps file (re)caused a crash.

I do not think it is necessary to prevent installations to directories with non-safe characters. However, a warning with the possibility to go back would be nice. The installer already warned about spaces, so I opted not to use them. However, the installer allowed to use parenthesis so, since it warned about a similar issue, I though it would be safe to use them.

/OP (also comment #4 is mine)

Anonymous
Mon 28 Nov 2016 07:07:07 PM UTC, comment #5: 

For the OP - does printing to an svg file also cause Octave to crash? By "crash" you mean that Octave exits immediately, right?

The reporter has said that printing to an eps failed in the same way, but I see that even the eps format makes a call to the external epstool utility. Looks like printing to svg is the only one that doesn't use any external programs, only cat.

I agree that it has been suggested before to only install Octave in directories with safe character sets. Maybe I am in the minority but I think it should be possible to install Octave in a directory with any name, and I'm willing to test for and fix things that break because of that, assuming I'm able to reproduce the error on a GNU system.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Nov 2016 07:00:51 PM UTC, comment #4: 

The default install directory was C:\Octave\Octave-4.2.0\, which I chose not to use. The installer did not allow installing into "C:\Program Files (x86)\Octave\Octave-4.2.0\" due to spaces in the directory name. However, it did allow installing to the directory C:\Program_Files_(x86)\Octave\Octave-4.2.0\ .

I used the default graphics toolkit, which seems to be qt.

I think a safe way would be to raise a note about possible problems during the installation if the installation directory contains questionable characters.

Anonymous
Mon 28 Nov 2016 06:41:24 PM UTC, comment #3: 

The reporter is running Microsoft Windows.  From what I remember, this issue has happened before and it isn't Octave's problem per se.  It is the fact that when printing we use gl2ps to get to an intermediate format of eps, and then use ghostscript to further transform the intermediate into the final output format.  It is the sub-process call out to a shell to invoke ghostscript which I believe has problems.

The simplest solution has always been to just install Octave in a directory without whitespace or any other questionable characters.  That's why I'm interested in whether our installer is now defaulting to installing Octave in an incorrectly named directory.  It shouldn't do that, but if the user manually selected an install directory then we would have to honor that choice.

Rik <rik5>
Project Administrator
Mon 28 Nov 2016 06:03:21 PM UTC, comment #2: 

FWIW, this works for me on Debian, if I install Octave 4.2.0 into "/some/directory/Program Files (x86)/Octave/Octave-4.2.0", both spaces and parentheses in the directory name. I can print figures and run the full test suite with no problems.

Only one test fails, "test doc", I'll fix that one shortly if it's simple enough.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Nov 2016 05:30:10 PM UTC, comment #1: 

Did the Octave installer default to the directory

C:\Program_Files_(x86)\Octave\Octave-4.2.0\

or did you select the directory containing "_(x86)"?

Also, what graphics toolkit were you using?  If one of the OpenGl toolkits (qt or fltk), does it work if you use gnuplot?

Rik <rik5>
Project Administrator
Sun 27 Nov 2016 09:09:50 PM UTC, original submission:  

I installed Octave 4.2 using the installer to C:\Program_Files_(x86)\Octave\Octave-4.2.0\ and tried to print a figure with no luck. I tested printing as eps, png and pdf. I tried "save as" from the figure menu as pdf. Octave crashed every time.

I uninstalled the program, reinstalled it to C:\Program_Files\Octave\Octave-4.2.0\ and replotted with success (tried only png with print -command).

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #47804:  pdflatex.log added by dasergatskov (25KiB - text/x-log)
file #47803:  oct-H4Vfne.eps added by mmuetzel (164KiB - application/postscript)
file #47791:  bug49718_print_with_spaces.patch added by mmuetzel (7KiB - application/octet-stream)
file #47792:  print_diary.txt added by mmuetzel (15KiB - text/plain)
file #47441:  quote_popen5.patch added by pantxo (9KiB - text/x-patch)
file #47405:  quote_popen4.patch added by pantxo (8KiB - text/x-patch)
file #47400:  quote_popen3.patch added by pantxo (7KiB - text/x-patch)
file #47401:  print_coverage.m added by pantxo (2KiB - text/x-objcsrc)
file #47381:  quote_popen.patch added by pantxo (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by arm_in (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5
  • -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 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-04 dasergatskov Attached File- => Added pdflatex.log, #47804
    2019-11-04 mmuetzel Attached File- => Added oct-H4Vfne.eps, #47803
    2019-11-03 mmuetzel StatusPatch Submitted => Ready For Test
    2019-11-03 mmuetzel Attached File- => Added bug49718_print_with_spaces.patch, #47791
        Attached File- => Added print_diary.txt, #47792
    2019-09-03 rik5 Carbon-CopyRemoved 72865 => -
    2019-09-02 pantxo Attached File- => Added quote_popen5.patch, #47441
    2019-08-28 pantxo Attached File- => Added quote_popen4.patch, #47405
    2019-08-27 pantxo Attached File- => Added quote_popen3.patch, #47400
        Attached File- => Added print_coverage.m, #47401
    2019-08-25 pantxo Item GroupSegfault, Bus Error, etc. => Unexpected Error
    2019-08-22 pantxo Attached File- => Added quote_popen.patch, #47381
        StatusConfirmed => Patch Submitted
        Release4.2.1 => dev
    2019-04-13 mtmiller Carbon-CopyRemoved 80942 => -
    2018-03-16 pantxo Release4.2.0 => 4.2.1
    2016-11-28 rik5 StatusNeed Info => Confirmed
        Carbon-Copy- => Added lostbard
    2016-11-28 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5