Octave doesn't get along with TCC?

[vefatica]

Octave is a Gnu clone of MatLab. If I execute

D:\octave\mingw64\bin\octave-gui.exe --gui

from Start\Run, it works correctly.

If I execute

start D:\octave\mingw64\bin\octave-gui.exe --gui

from CMD, PowerShell, or PWSH, it works correctly.

The same START command issued in any TCC (tried a few, with/without plugins) gives me two message boxes:

---------------------------
Octave Documentation
---------------------------
Could not copy help collection to temporary
file. Search capabilities may be affected.
Cannot open collection file: \scratch\build\mxe-octave-w64\usr\x86_64-w64-mingw32\share\octave\9.1.0\doc\octave_interpreter.qhc
---------------------------
OK   
---------------------------


---------------------------
Octave Documentation
---------------------------
Could not setup the data required for the
documentation viewer. Maybe the Qt SQlite
module is missing?
Only help text in the Command Window will
be available.
---------------------------
OK   
---------------------------

Then the Octave GUI starts but the help (docked in the main window) is not functional.

It's OK if I issue that command without "start" in TCC.

So SQL and TCC's START command seem to have something to do with it.

My TMP and TEMP are, I believe, the default (C:\Users\vefatica\AppData\Local\Temp).

 

[vefatica]

Two notes:

1. Actually, Octave tries (and fails) to open

%TEMP\build\mxe-octave-w64\usr\x86_64-w64-mingw32\share\octave\9.1.0\doc\octave_interpreter.qhc

So the "scratch" in the message box is a left_over_from_unix way of saying %TEMP%.

2. When Octave starts properly (i.e, without TCC's START command) it doesn't try to open that file. Rather, it succesfully opens the same file in its own installation tree.

 

[rconn]

Running an app from the command line calls the same code as START. Apparently the (Linux?) developers of Octave aren't handling the Windows startup quite right (not the most surprising thing in the world).

I'll download Octave and see if I can reproduce / kludge around it.

 

[rconn]

I installed the latest version of Octave, and it starts successfully from the TCC command line with either:

start "Octave" "C:\Program Files\GNU Octave\Octave-9.1.0\octave-launch.exe" --no-gui

or

start "Octave" "C:\Program Files\GNU Octave\Octave-9.1.0\octave-launch.exe" --gui

or

start /PGM "C:\Program Files\GNU Octave\Octave-9.1.0\octave-launch.exe" --gui

Maybe a problem with your environment?

 

[vefatica]

Try my command with an appropriate path (to octave-gui.exe).

start D:\octave\mingw64\bin\octave-gui.exe --gui

With START the error occurs (not with other shells). Without START the error does not occur.

I checked on octave-gui.exe's environment. TEMP/TMP are set correctly (C:\Users\vefatica\AppData\Local\Temp).

 

[rconn]

Why do you want to start Octave in a different way than what the developers want you to?

 

[vefatica]

Why do you want to start Octave in a different way than what the developers want you to?

Because the launcher stays running ... for no other reason than to return the exit code of whatever it launches to the shell.

I agree, Gnu stuff can get pretty odd. Nevertheless START (vs. no START) causes bad things to happen.

 

[vefatica]

... and the launcher, being a CUI app, makes TCC wait for it to exit.

 

[rconn]

There are a couple of things going wrong here:

1. octave-gui.exe is not a GUI app; it's a console app that then starts a GUI app. So START is going to create a new empty console window for it that will hang around until you exit the GUI app. This is not TCC-related; CMD will do the same thing. You don't get the extra window when not running START, because TCC (and CMD) assume if you didn't use START, you want to run the app in the current console window.
2. Octave is gorking on the pathname passed to it by START. TCC will change the path/program name to upper case (to emulate an old CMD.EXE bug/feature). Octave doesn't seem aware that Windows filenames are case-insensitive (not unusual for Linux developers trying to port apps to Windows).
3. I could remove the upper-casing code from START, at the risk of it then failing for an unknown number of commands where it used to work. I'm reluctant to do that for the sake of one user who wants to run one app in an undocumented fashion.
4. If you're determined to do it this way -- use DETACH instead of START. You won't get the extra empty console window, and TCC won't try to emulate old CMD behavior.

 

[vefatica]

All of the programs in question are CUI.

d:\octave> echo %@exetype[octave-launch.exe]
10

d:\octave\mingw64\bin> echo %@exetype[octave.exe]
10

d:\octave\mingw64\bin> echo %@exetype[octave-gui.exe]
10

Don't change anything. The more I play with it, the screwier it seems to be.

 

[AnrDaemon]

START "title" "X:\path\to\object"

Do NOT skip the "title" part. Else START may confuse object to title and the results would be far from desired.