I just built stable version 4.4.0x and verified the fix works.

and to mxe
http://hg.octave.org/mxe-octave/rev/a800e350d88b

I think it does need to go on stable.  The issue that motivated this report is that certain packages would fail to install correctly on stable.  I suppose if there is a more minimal way to insure that we could use that solution, but it sounded like it would require review of every single Octave Forge package and swapping octave.exe with octave-cli.exe.  In that case, I'd rather fix Octave core so that the packages can remain as written.

updated patch to include the bash stub to the bat files

(file #44515)

statistics is overriding octave.

I created the octave changes patch from the stable branch so at least it should merge cleanly.


However .....


I just tried the strings package which I see has $(shell $(OCTAVE)) call in its make file and it fails at that point because it is running in a bash  shell and do doesn't know the DOC commands used in bat files

>> pkg install -verbose -forge strings
mkdir (C:\Users\JOHN\AppData\Local\Temp\oct-MI6SEN)
untar (C:\Users\JOHN\strings-1.2.0.tar.gz, C:\Users\JOHN\AppData\Local\Temp\oct-MI6SEN)
C:/Octave/OCTAVE~4.0/bin/octave-5.0.0.bat: line 1: @echo: command not found
C:/Octave/OCTAVE~4.0/bin/octave-5.0.0.bat: line 2: Rem: command not found
C:/Octave/OCTAVE~4.0/bin/octave-5.0.0.bat: line 9: syntax error near unexpected token `('
C:/Octave/OCTAVE~4.0/bin/octave-5.0.0.bat: line 9: `for %%I in ("%OCT_HOME%") do set OCT_HOME=%%~sI'
make: Entering directory `/tmp/oct-MI6SEN/strings-1.2.0/src'
C:/Octave/OCTAVE~4.0/bin/mkoctfile-5.0.0.exe --verbose  -o pcregexp.oct pcregexp.cc
g++ -c -I/home/johnd/mxe-octave/build-64/usr/x86_64-w64-mingw32/include  -IC:\Octave\OCTAVE~4.0\include\octave-5
.0.0\octave\.. -IC:\Octave\OCTAVE~4.0\include\octave-5.0.0\octave -IC:\Octave\OCTAVE~4.0\include   -fopenmp -g -
O2    pcregexp.cc -o C:/Users/JOHN/AppData/Local/Temp/oct-gpBQRQ.o
pcregexp.cc: In function 'octave_value_list Fpcregexp(const octave_value_list&, int)':

And to make more fun,  from octave, running system("octave.bat") works fine as it is then using the windows shell.

Im not sure what other repercusions there would be if we just change the shell variable in the scripts

This will take me several hours, but I'll apply both patches and see what happens.

and the patch mentioned in comment #12 ....

(file #44511)

I think this probably requires John D. to make the necessary changes.  However, I am attaching a start which puts octave.bat in the bin directory and makes the installer rely on finding octave-cli.exe rather than octave.exe to determine whether Octave exists.



(file #44495)

Mike's proposal in comment #8 seems sensible.  For consistency, I would get rid of octave-cli-4.4.0.exe as well since there is no analog in the GUI such as octave-gui-4.4.0.exe.  Thus, I'm left with

.../Octave 4.4.0/octave.vbs
.../Octave 4.4.0/bin/octave.bat
.../Octave 4.4.0/bin/octave-4.4.0.bat
.../Octave 4.4.0/bin/octave-cli.exe
.../Octave 4.4.0/bin/octave-gui.exe

Should this change be done on stable before the 4.4.1 release, or is it too much change?  If yes, should probably alert jwe to the work being done here.

We would also have to copy octave.bat into the bin directory. It currently only sits at the Octave root directory (OCTAVE_HOME). We would also have to copy octave.bat to octave-4.4.0.bat so that the versioned program name can be used.

I still advocate for deleting octave.exe completely. It should not be used at all. Both octave.bat and octave.vbs call octave-cli.exe or octave-gui.exe directly, octave.exe is just wasting space and adding confusion for users who poke around in the directory.

Added change to start octave without 'start' from octave.bat when non gui mode.
http://hg.octave.org/mxe-octave/rev/d1d36bdbc1ae

I think we should make it so that calls to ${OCTAVE_HOME}/bin/octave and ${OCTAVE_HOME}/bin/octave-${VERSION} call the octave.bat script instead of the octave.exe program. The purpose of octave.bat is to replace octave.exe, so I think it should replace it in all instances.

Inside of Octave, the user should be able to rely on ${OCTAVE_HOME}/bin/octave-${VERSION} being a well-known entry point that can be called in a useful way regardless of the operating system.

If octave.bat is copied into bin/octave.bat and bin/octave-4.4.0.bat, does it automatically take precedence over bin/octave.exe and bin/octave-4.4.0.exe? Then the only change necessary in configure_make would be to drop the exe extension.

I think everyone agrees that 'octave.exe --no-gui' should not be used. In fact, I thought it was also generally agreed on that octave.exe should never be used, that's why we have octave.bat and octave.vbs. And that's why the '--no-gui' as an option runs octave-cli instead of octave-gui.

I would say on GNU and Unix systems there are three modes, 'octave-cli', 'octave --no-gui' (default), and 'octave --gui', but on Windows there are only two modes that work. If we can make that easier somehow by adding options to the bat file or deleting the octave.exe that users shouldn't be using, we should do so.

IMHO calling 'octave --no-gui --no-window-system' should end up executing 'octave-cli' on all platforms.

Can we make octave.bat call 'octave-cli.exe' insetad of 'start octave-cli.exe' as a first step?

What do you mean by calling octave-cli "doesnt get passed through the pkg build system as a variable"? Meaning that the configure script still gets called with OCTAVE=$fullpath/octave-4.4.0?