bugGNU Octave - Bugs: bug #53070, Empty search path when starting...


bug #53070: Empty search path when starting Octave from TCC/LE (alternative Windows command prompt)

Submitted by:  Peter Langer <plg25>
Submitted on:  Mon 05 Feb 2018 03:06:52 PM UTC  
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.2.1Operating 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 Jump to the original submission)

Fri 09 Feb 2018 07:29:12 AM UTC, comment #8:

The renaming of the bug is OK!

Trying octave.vbs instead of octave-gui.exe in TCC-LE (because octave.bat is not working):
1. On the local computer(Win7): it’s just works fine (e.g. D:\Programme\Octave-4.2.1\Octave.vbs test.m)
2. On the local computer this works too: \\R176\BKG_Programme$\Octave\Octave_4.2.1\Octave.vbs test.m
3. using a remote session on one computer in the cluster (Windows 2012 Server R2) this works too: C:\BKG_Programme\Octave\Octave_4.2.1\Octave.vbs test.m
4. using a remote session on one computer in the cluster (Windows 2012 Server R2) the following makes errors (ghostscript related): \\R176\BKG_Programme$\Octave\Octave_4.2.1\Octave.vbs test.m
warning: called from
_print_parse_opts_>__ghostscript_binary__ at line 506 column 26
_print_parse_opts_ at line 190 column 31
print at line 315 column 8
test.m at line 159 column 1
warning: print.m: Ghostscript binary is not available.
Only eps output is available.
warning: called from
_print_parse_opts_ at line 382 column 7
print at line 315 column 8
test.m at line 159 column 1
error: _ghostscript_.m: ghostscript is required.
error: execution exception in test.m

5. If I put the input from 3. in a job and arrange it that way, that the job is running at the same computer in the cluster like used for the test in 3. the job does not run. If I replace Ocatve.vbs again and use octave-gui.exe instead the job runs in the cluster.

The mentioned printing issue:
- Yes, I’m using a remote headless computer.
- Yes, I already tried different graphics_toolkits. Ordninary “qt” is used. The warnings I already posted in comment #6 are a result from using “qt”. I used the following command:

print('figure3.png','-dpng', ['-S' num2str(1200) ',' num2str(768)]);

The funny thing is: It’s working fine, if I use:

print('figure3.png','-dpng', ['-S' num2str(1000) ',' num2str(667)]);

- The toolkit “fltk” it not working right.
- With “gnuplot” the size of the graphic is OK. The whole graph but looks ugly because the linewidth is the same all over the graph.

Whit all those problems I'm fighting right now I’m getting the feeling not to be right with octave. Maybe I should get python with matplotlib a chance.

Peter Langer <plg25>
Wed 07 Feb 2018 07:49:34 PM UTC, comment #7:

I renamed the bug to reflect that the issue is actually caused by starting Octave from a TCC prompt.
The octave.bat file sets some environment variables before starting Octave. You might consider setting those manually if you can't call the .bat file. Have you tried with octave.vbs?

Wrt the printing issue: Are these remote computers headless? I think there are some issues with off screen printing and certain graphics drivers.
Bug #44338 is still open. But I think there is already a solution that will be available with the next release of Octave (distributing our own OSMesa?). Maybe that was discussed on the mailing list...
In the meantime you could try with a different graphics toolkit. Run "graphics_toolkit" to get a list of the toolkits available on your system.

Markus Mützel <mmuetzel>
Project Member
Wed 07 Feb 2018 08:52:38 AM UTC, comment #6:

I have to apologize a little bit. The reason for the empty search path in Octave is not the network share! It’s the way I start Octave. With my own batch script I always started the octave.bat. But when I do that, I do not use cmd.exe but the TCC/LE command prompt replacement from jpsoftware. (The reason for the use of TCC is the not supported unc-path in cmd.exe.)
Using TCC to start octave.bat leads to the problem with the empty search path in Octave. (It has to be the start command in the octave.bat …) It doesn’t matter, if I start it from a network share or a local disk. The search path in octave will be empty both ways. If I directly start the octave-gui.exe from the bin directory everything is fine. So in my batch scripts I replaced the octave.bat with octave-gui.exe and now Octave starts with search paths!
In my opinion the report can be closed. Markus thank you for your support. I really appreciate that you took the time to answer my question!

Now I have a next question and don’t know: it’s a bug or a feature? If I run my batch file by manually starting it on a local computer it is running just perfect(Windows 7 Pro and Windows 2012 Server R2). If my batch file is started trough the jobsystem in the HPC-cluster on a randomly chosen remote computer(Windows 2012 Server R2) I get the following warnings:

warning: gl2ps_renderer::draw_axes: empty feedback buffer and/or nothing else to print
warning: called from
_opengl_print_ at line 169 column 7
print at line 519 column 14
test.m at line 158 column 1

It seems to me, that this has something to do with bug #44292. Should I open a new bug-report?

Peter Langer <plg25>
Tue 06 Feb 2018 08:41:05 PM UTC, comment #5:

Is "D:\Programme" your default location for Program Files?
On my German installation of Windows 10, I see "C:\Programme" for the folder where the (64bit) programs are installed. However, if I browse into that folder with Windows Explorer and click into the address bar, it actually shows "C:\Program Files" (containing a space character).

Could you try installing Octave to e.g. "D:\Octave" and see whether the problem persists?

I tried to duplicate but don't see the same error. How do you execute the batch file? When I am starting it from a PowerShell, I see the following message, Octave opens, the m-file does not execute but the search path is set correctly:

Markus Mützel <mmuetzel>
Project Member
Tue 06 Feb 2018 09:04:41 AM UTC, comment #4:

Right now Octave is installed on a local hard disk. The installation path is “D:\Programme\Octave-4.2.1”, no non ASCII characters or spaces. The batch file just has one line and looks like:

D:\Programme\Octave-4.2.1\octave --persist test.m

Ordinary I do not use the --persist. It’s just there to figure out, what’s the problem is.

In the near future I would like to use an Octave installation on a network share.

The new title is OK!

Peter Langer <plg25>
Tue 06 Feb 2018 08:43:54 AM UTC, comment #3:

Sorry, I misunderstood what the problem was.
Is Octave installed on the network share as well? Or on a local disc?
IIRC, Octave cannot be run if it is installed on a path that contains non-ASCII characters (related to bug #49118) or spaces either. That might be caused by a similar reason.

Re-opening and changing title. Does the new title reflect your issue?

Markus Mützel <mmuetzel>
Project Member
Tue 06 Feb 2018 08:31:58 AM UTC, comment #2:

I’m not quite sure that the reported is the same like in bug #51268. The problem is, that absolutely no search path is included in Octave, if you start Octave from a batch file on an network share, which is not mounted with a drive letter (unc)! The same happens, if you use an older version of Octave (I tested 4.0.3). --> It’s more like a general Octave problem. To use a mapped drive is unfortunately not possible, because Octave is used in a long chain of calculations, which do not support mounted drives with a letter (HPC).

Peter Langer <plg25>
Mon 05 Feb 2018 05:30:47 PM UTC, comment #1:

This is probably a known error in the current release which was fixed in bug #51268.
Until the next release, you could assign a drive letter to the network share which should work.

Closing as duplicate.

Markus Mützel <mmuetzel>
Project Member
Mon 05 Feb 2018 03:06:52 PM UTC, original submission:

If I start a batch file from a local disk Octave does everything right!
If I start the same batch file from a network share (not mounted with a drive letter in windows but just as a network connection (unc path)) nothing works. I think that the search path is set totally wrong(none). Compare the screenshots I have attached. The empty search path belongs to: running the batch file from the network. Why is it that different? What is to do?

Peter Langer <plg25>


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

Attach File(s):

Attached Files
file #43176:  hc_2244.png added by plg25 (7KiB - image/png)
file #43177:  hc_2243.png added by plg25 (61KiB - image/png)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by plg25 (Submitted the item)

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

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 07 Feb 2018 07:49:34 PM UTCmmuetzelSummaryEmpty search path when running Octave from a network share (UNC path)=>Empty search path when starting Octave from TCC/LE (alternative Windows command prompt)
    Tue 06 Feb 2018 08:43:54 AM UTCmmuetzelStatusDuplicate=>None
      Summaryrunning batch script from local hard drive via running it from a share (unc-path)=>Empty search path when running Octave from a network share (UNC path)
    Mon 05 Feb 2018 05:30:47 PM UTCmmuetzelStatusNone=>Duplicate
      Dependencies-=>Depends on bugs #51268
    Mon 05 Feb 2018 03:06:52 PM UTCplg25Attached File-=>Added hc_2244.png, #43176
      Attached File-=>Added hc_2243.png, #43177

    Back to the top

    Powered by Savane 3.1-cleanup1