Command-line `octave` invocations do not get our environment setup

[apjanke]

The AppleScript launcher script for Octave.app sets up several environment variables necessary for octave to work properly when running from the Octave.app app bundle. This includes:

• PATH
• GNUTERM
• DYLD_FALLBACK_LIBRARY_PATH
• FC
• GS_OPTIONS
• LANG

There's also the whole font cache thing, which I don't really understand.

This works when you double-click the Octave.app icon to launch it.

If you run the octave or octave-cli binaries from the Octave.app app bundle directly from the shell, the startup script is bypassed, and you don't get these environment variables setup properly, so some things won't work, like plotting with the gnuplot toolkit, compiling Fortran oct or MEX files, some Ghostscript stuff, and who knows what else.

Caused #206.

Running Octave.app's octave from the shell like this isn't a major use case for Octave.app, since it's intended for use as a Mac GUI app. But it's nice to do for debugging purposes, is a workaround for the "GUI freezing in 5.x+" issue, and apparently at least some of our users like to do it. So it would be nice if that worked.

This also impacts the usefulness of using the octave-octave-app* formulae directly in a Homebrew installation: since they're not run from the app bundle, there's no AppleScript startup script to set up the environment for them.

Possible approaches

We could move all the environment setup out of the main AppleScript main.scpt launcher script and into bash wrapper scripts around octave and octave-cli, dropping those bash wrapper scripts into the usr/bin/ under Octave.app. That wouldn't even conflict with anything, I think, since the octave-octave-app formulae are keg-only. Hmmm. That might actually be a more convenient way to manage the generation of the script that does environment setup anyway; the multiple levels of quoting needed in the bash embedded in the AppleScript embedded in the bundle_octave bash script are kind of a pain to work with.

Maybe the font-config cache stuff should be pushed down into different wrapper scripts or .octaverc, too, so it's picked up when launching from the shell.

We could also supply a separate setup_octave_app_env.sh script for users to source before calling the octave binaries from inside Octave.app.

References

Related issues:

• https://github.com/octave-app/octave-app/issues/225

[apjanke]

Pinging @schoeps. This would be a significant change to the design of how we do the launcher script(s), but I think it might be useful to have, and make our work easier going forward. I think it might also make it easier to support a CLI-only build or mode of Octave.app, which could help with the freezing-GUI issue. What do you think?

[schoeps]

Agreed! I don't know why I did not do it with an additional script back in the day. I guess there was a reason because it's so obvious and I recall that the quoting was a coding nightmare. Maybe I liked it to have only a single file? This may have been advantageous for sharing? I am all in favor of a bash script!

[apjanke]

I don't know why I did not do it with an additional script back in the day.

I bet you did it because the installation path is maybe version-dependent, and is readily available as a variable for string interpolation in the bundle-octave bash script? To do the external wrapper scripts, I'm going to have to create "template" files and process them as part of the build/munge process.

Okay, I'm going to give this a try!

[rdzman]

FWIW, I almost always launch Octave (and Matlab, for that matter) from the CLI, so that it can run a different startup.m script depending on where I launch from. And this is with and w/o GUI.

So, I appreciate any efforts to make everything work so that a CLI launch and double-click are equivalent in every other way.

And thanks for all your work on developing and maintaining this package. It's what makes it possible for me to easily keep several versions of Octave installed and active for testing.

[apjanke]

FWIW, I almost always launch Octave (and Matlab, for that matter) from the CLI, so that it can run a different startup.m script depending on where I launch from. And this is with and w/o GUI.

Interesting; I didn't know anyone was using Octave.app that way. (We need to learn more about our users.)

How are you launching Matlab from the CLI? I'm a heavy Matlab user too, but I never launch Matlab from the shell on Mac.

And thanks for all your work on developing and maintaining this package.

You're welcome! Thanks for letting us know you're using it.

[rdzman]

When I install a new Matlab version, I do, for example ...

sudo ln -s /Applications/MATLAB_R2020a.app/bin/matlab /usr/local/bin/matlab

Then I just launch it with ...

matlab &

... if I want to use the GUI. But mostly I just use the command line in the Terminal, so I have the following shell alias that I use to launch it without the GUI.

ml='env EDITOR=bbedit matlab -nodisplay'

I do something similar for Octave, and in fact, I actually use symlinks and aliases to specific versions so I can easily launch the version I want.

[apjanke]

Ah, cool. Thanks!