[Octave] [Openbox] Fails to open when run directly by Openbox

aphirst · 2018-01-25 16:12:02

I run Openbox as my WM (no DE), and lightdm as my login manager. I have an entry in my standard Openbox menu which should open Octave. I also have the launcher application "gmrun" set to be opened directly by Openbox on a hotkey press.

What I expect to happen is for the Octave GUI to open. What happens is nothing, not even a dangling "octave" entry in htop.

However, if I open a terminal emulator (xterm, sakura, etc.), and run octave in there, the Octave GUI appears. More strangely, if I run "gmrun" within the terminal emulator, then try to run Octave from here, it works!

It looks as if there's something different between "run by Openbox" and "run by terminal emulator", presumably something in my .bashrc or .bash_profile. Here's my .bashrc, and my .bash_profile only contains

[[ -f ~/.bashrc ]] && . ~/.bashrc

In my .xinitrc I have

export DE="lxde"
export DESKTOP_SESSION="lxde"
exec openbox-session

though I must confess, I have forgotten why I set those two variables.

In my openbox "environment" file I have this, and all I have in my autostart are tint2, redshift-gtk, pasystray, indicator-keylock, blueman-applet, and feh for a wallpaper (all backgrounded with &).

Obviously, since the issue is stuff run directly by openbox, it's not clear to me how to get any error messages or debug output of any kind. I'd appreciate any suggestions, or at least, confirmation of the issue from someone else not running a full DE.

Software versions:

octave 4.2.1-8
openbox 3.6.1-3

Last edited by aphirst (2018-01-25 16:15:02)

seth · 2018-01-25 16:56:40

~/.xsession-errors or journal?

tr '\0' '\n' < /proc/$PID/environ

will allow you to inspect environmental differences between openbox and bash (substitute $PID accordingly)

aphirst · 2018-01-25 17:12:30

Nothing shows up in .xsession-errors. Which journal do you mean? Nothing shows up in journalctl -xe.

https://ptpb.pw/AHAQ-VPJgfbgFwUHYAe9w8UTvQgx Shows the environment for both openbox and bash. (I used htop to determine the PIDs of openbox, and of a bash session in sakura/xterm).

The diff looks large, but I noticed the entries were all in different orders. After "sort"ing both, and doing another diff, this was the result:

[adam@rakka ~]$ diff env_sorted_openbox.txt env_sorted_bash.txt 
1a2
> COLORTERM=truecolor
39a41
> TERM=xterm-256color
40a43
> VTE_VERSION=5002

Unless one of these three variables is significant in some way (unlikely?), the issue must lie elsewhere.

seth · 2018-01-25 17:21:25

What if you wrap octave in a shell script and redirect its output to some file, like "octave > /tmp/octave.bug 2>&1"

aphirst · 2018-01-25 17:24:37

With just "octave" before the >, I get nothing at all. If I replace that with "octave --verbose", I get

executing commands from /usr/share/octave/site/m/startup/octaverc ... done.
executing commands from /usr/share/octave/4.2.1/m/startup/octaverc ... done.

But of course, octave still doesn't open.

ayekat · 2018-01-25 17:56:57

Try artificially keeping stdin open:

octave </dev/tty

--edit: Not sure if /dev/tty is the best option, but it works for me™

Last edited by ayekat (2018-01-25 18:07:31)

Trilby · 2018-01-25 18:04:26

ayekat is right. I just confirmed octave (for some absurd reason) needs stdin to be connected in order to run a gui.

You can confirm by redirecting dev/null to it's stdin in a terminal: it will exit in precisely the same way as from your menu.

The real workaround for this is to use the flag "--force-gui"

Last edited by Trilby (2018-01-25 18:06:07)

aphirst · 2018-01-25 18:12:53

@ayekat, as I mentioned in IRC, that doesn't work for me. Maybe a different tty would, but then you mentioned that there was another reply, so I refreshed the page.

@Trilby, yes, --force-gui does work, which is great to know for now. However this necessitates some follow up, I think. I neglected to mention in this thread, that, while investigating another octave bug (which I posted about on the Octave Help mailing list), I've also tried out Octave under fluxbox. One of my side-findings is that octave (no flags) run under fluxbox's "Alt+F2" run dialog DOES load. Does this mean that fluxbox, for whatever reason, is "providing" stdin to binaries it executes? If so, why does Openbox not?

Trilby · 2018-01-25 18:43:34

aphirst wrote:

Does this mean that fluxbox, for whatever reason, is "providing" stdin to binaries it executes? If so, why does Openbox not?

fluxbox's run command needlessly runs everything through a shell, openbox uses glib's g_spawn functions which in turn call exec family functions after explicilty closing all file descriptors.

They are written by different people, that's why.

Octave depending on either one of those behaviors or the other is silly. A gui program may do different things if it has stdin connected or not, but it absolutely shouldn't depend on it. The entertaining bit here is that octave is a gnu project, and it fails to run when launched with gnu's spawn function (thanks for reinforcing my signature!)

Last edited by Trilby (2018-01-25 18:44:59)

JordiGH · 2018-01-25 18:59:15

Trilby wrote:

The entertaining bit here is that octave is a gnu project, and it fails to run when launched with gnu's spawn function (thanks for reinforcing my signature!)

Hi Trilby. GNU Octave maintainer here. I am glad we entertained you. Can you help us fix it? I believe the relevant bits of code are here:

http://hg.savannah.gnu.org/hgweb/octave … in.cc#l348

Trilby · 2018-01-25 19:09:29

Thanks for joining us here JordiGH. Am I missing something or is the relevant "--force-gui" flag not parsed in that file? If that flag has been removed recently then I'd first want to check if the current code has already fixed the issue.

EDIT: via `strace -f` I can confirm that even in the version currently in our repos, the fork does occur, the qt/x libs are loaded. I suspect (I'm still reading the trace) that the window is simply never mapped as when there is an attempt to read from stdin and the equivalent of an EOF is received, octave closes down "normally". Note that it doesn't exit with an error, it just exits as if it was given an empty script to run.

Last edited by Trilby (2018-01-25 19:15:34)

JordiGH · 2018-01-25 19:16:48

Ah, I had forgotten about the --force-gui option.

It appears that this is in fact the intended solution to the problem.

http://hg.savannah.gnu.org/hgweb/octave … ui.cc#l112

Trilby · 2018-01-25 19:28:22

If you are open to it, I'd encourage you to remove the assumption that stdin not being a tty means it must be a file: there are many other alternatives.

Instead, use `fstat`. If you give it a closed file descriptor it will give an EBADF error (then you should continue with the gui). On success you can check the returned st_mode and do what you wish for different types of stdin (probably read from any of them and exit when nothing is left). So the initial check for a failed fstat with EBADF would be the necessary change.

As it currently stands, the logic is basically "if it doesn't exist, it must be a file!"

Or even easier, if you really are going to read from every other possible input, just revise line 118:

-    if (! octave_isatty_wrapper (fileno (stdin)))
+    if (fileno(stdin) != -1 && ! octave_isatty_wrapper (fileno (stdin)))

EDIT: as the octave developer has failed to follow up on this, I've just submitted a bug report upstream with this patch and the suggestion that they change their logic to something more ... logical.

Last edited by Trilby (2018-02-02 23:42:49)

mtmiller · 2018-02-02 22:33:52

Hi, Octave developer here. Just wanted to offer that I am willing to help debug and work with anyone who thinks there is an issue here that needs fixing in Octave

I have personally tested the patch provided and it hasn't seemed to make any difference under several different conditions, but I am very happy to review or discuss further ideas for improvement.

JordiGH · 2018-02-02 22:43:40

Trilby wrote:

EDIT2: Nevermind that bug report, it won't make headway. I was previously just poking a bit of fun, but upstream really are fuckwits here.

Please be more kind than that. I didn't get a notification about a patch in this forum. Did you edit your message after the first reply? I discussed the problem with others but my Octave activity has dwindled to almost nothing during the past couple of years. I just try to help with a few things here and there.

Patches sometimes take a long time to get addressed, but they're never truly forgotten. Also, in terms of priorities, this one isn't a big one, so it's reasonable if it doesn't get handled right away. I'm glad that Mike has picked it up.

Trilby · 2018-02-02 23:29:27

JordiGH, my intent wasn't to be unkind. But frankly the discussion on the bug tracker is a bit disturbing. Octave is a numerical computing tool where precision and correctness are of utmost importance. Yet in handling this issue there was such apathy to a clearly illogical approach when a correct logical approach was readily available.

This paired with the apparent lack of knowledge on how to use a basic system call like `stat` is ... well lets just say it's not inspiring for the precision and correctness of the calculations that would be performed by octave.

Certainly this issue is trivial compared to having the right algorithms for the actual computational work, but slopy thinking/coding in such a tool, even at this 'trivial' level undermines confidence in the rest of the code - at least for me. But as I said on the bug tracker, it's really none of my concern as I already don't use octave myself (however I have thought highly of it and recommended students learn to use it).

EDIT: I've removed my admittedly snarky previous comment. If you're both working on it that deserves recognition: I appreciate that. However, the points in this post still stand: it's not hard to do it right. If you want to know if stdin is a file (or file-like pipe), really, just check if stdin is a file/file-like and be done with it. Assuming stdin is a file because isatty does not return true is just bad. There are many ways isatty will return false without stdin being a file. There are also many ways isatty could just fail. Certainly a failed test of any sort can't be positive evidence that stdin is a file.

Get rid of the whole "--force-gui" thing: that is a work-around for what was done wrongly in the first place. Don't write workarounds for bad code, just fix the bad code (i.e. see point #3).

Last edited by Trilby (2018-02-02 23:50:53)

mtmiller · 2018-02-03 01:02:10

Trilby wrote:

frankly the discussion on the bug tracker is a bit disturbing

Yes, we certainly thought it was.

Trilby wrote:

Yet in handling this issue there was such apathy to a clearly illogical approach when a correct logical approach was readily available.

You have claimed that the more logical approach is to check stdin to see whether it is a file. I agree that that is a logical approach. You have also claimed that a process will have stdin closed by a graphical launcher. I think that you are mistaken. Therefore, I disagree on the relative importance of this bug. But I will be happy to be proven wrong. I would love to be able to eliminate --force-gui and have Octave discern between a terminal, a valid file (which includes /dev/null), and a graphical launcher context.

Trilby wrote:

apparent lack of knowledge on how to use a basic system call like `stat`

Hmm? There were only three of us there, and I think it's safe to assume you don't mean yourself.

Oh, I see. I think you confused my request for you to contribute a patch that actually does something with a lack of knowledge on my part. I can assure you I am well versed in POSIX and systems programming. I would just rather the other party put in some effort and contribute a change when they think our code is so horrendously wrong.

Trilby wrote:

But as I said on the bug tracker, it's really none of my concern as I already don't use octave myself (however I have thought highly of it and recommended students learn to use it).

Good, thank you for recommending Octave to others. I hope that you continue to recommend and think highly of it, we have a large community of volunteers working to maintain and improve Octave.

I am sorry that you don't think it's worth contributing any more of your time to help fix what you see as an egregious error. But even submitting a bug report is a contribution, so thank you for your contribution so far.

I'm only here to let others know that your characterizations may be a little off, we welcome all contributions, and I hope someone affected by this may provide some working code or at least some test cases to help us out a bit.

Trilby · 2018-02-03 01:51:03

*Sigh*

I regret giving the benefit of the doubt and removing my previous comment in this thread. "Fuckwits" was fitting:

/* return 0: socket, fifo, or regular file, read as "script"
 * return 1: not one of the above: run gui
 */
int is_filelike() {
        struct stat sb;
        if (fstat(fileno(stdin), &sb) == -1) {
                perror("fstat");
                return 1;
        }
        switch (sb.st_mode & S_IFMT) {
                case S_IFREG: case S_IFSOCK: case S_IFIFO:
                        return 0;
                default:
                        return 1;
        }
        return 1;
}

I will stop recommending octave.

Last edited by Trilby (2018-02-03 02:15:28)

seth · 2018-02-03 10:17:30

mtmiller wrote:

You have claimed that the more logical approach is to check stdin to see whether it is a file. I agree that that is a logical approach.

Good. It seems everyone agrees that the present input check in octave is insufficient. Thus should certainly be improved to everyones (inconclusive) benefit.

mtmiller wrote:

You have also claimed that a process will have stdin closed by a graphical launcher. I think that you are mistaken.

He did at least not explicitly and in this thread, but I assume that we can all agree that one can easily enough come up with a stupid dmenu script that leaves the stdin open to every process and the falsification of a real life scenario is impossible due to unlimited time and options and stupidity.

mtmiller wrote:

Therefore, I disagree on the relative importance of this bug.

mtmiller wrote:

I would love to be able to eliminate --force-gui and have Octave discern between a terminal, a valid file (which includes /dev/null), and a graphical launcher context.

While the first two discerns are proven possible, "graphical launcher context" is simply underspecified and cannot be detected for sure. It thus makes sense to keep a switch to enforce an interactive session, but that does not harm the idea to make such override as irrelevant as possible. Whether you want to alter default behavior of eg. char and block devices requires knowledge about your users (my guess would be that nobody would use octave eg. directly on a usb key, but hey: unlimited stupidity ;-) but the proper handling of a closed stdin should be obvious.

I'd suggest to "accidentally break™" octave and only use "reasonable" stdin types for non-interactive sessions, add a "--force-file" rescue and if ever somebody files a bug and insist to feed his device into octave, you're free to choose to call it a bug and fix that.

Trilby · 2018-02-05 20:07:14

Update - the upstream bug report was just updated. Mike took my code, deliberately modified it so that it would be completely useless, then ran a bunch of tests proving that it was useless, all so he could show off on the bug tracker.

If you want to test my code, test my code. If you want octave to remain broken, just leave it be.

mtmiller · 2018-02-05 20:39:36

I have incorporated the proposed additional checking into octave, a patch for testing and debugging and my notes are on the upstream bug report. The only meaningful change I made is to allow a character device as a valid input stream to octave, because it is.

To be clear, we do want 'octave < /dev/null' to act exactly the same as 'octave < empty_file.m'.

I have tried starting octave from the menuing systems in gnome, i3, and openbox, and none of them start octave with stdin set to something that I would call "closed".

To head off any speculation that octave, qt, or any of the dozen other libraries that octave uses are doing something suspect, I repeated my tests with a simple C program, with the same results.

I would really appreciate it if someone could define what they think they mean by octave or any program being started with a closed stdin.

If they mean /dev/null, or if they mean a valid open file descriptor that may be at EOF but a program won't know that until it tries to read from it, then I fear we have been talking past each other for days.

seth · 2018-02-05 21:14:36

https://superuser.com/questions/813472/ … ell-script

@Trilby, do you worry about the tty (which seems explicitly caught) or a specific char device?

Trilby · 2018-02-05 21:55:56

mtmiller wrote:

To be clear, we do want 'octave < /dev/null' to act exactly the same as 'octave < empty_file.m'.

I'm curious why, but I'm much more curious what that really means: do you want /dev/null input to behave like an empty file meaning no gui is launched but octave just exits without doing anything (this doesn't seem likely) or do you really mean you want an empty script file on the input to be treated like /dev/null input and launch the gui (which currently doesn't even happen)?

In any case, stat is still almost certainly the way to go. If you want to check the condition that the input is a file but empty, then check st_size from the stat return. In no case is `isatty` a sane way to handle this quesiton (yet this is what octave's current code does).

int is_filelike() {
        struct stat sb;
        if (fstat(fileno(stdin), &sb) == -1) {
                perror("fstat");
                return 1;
        }
        if (!sb.st_size)
                return 1;
        switch (sb.st_mode & S_IFMT) {
                case S_IFREG: case S_IFSOCK: case S_IFIFO:
                        return 0;
                default:
                        return 1;
        }
        return 1;
}

I'm not sure st_size will behave how you want on socket and fifo inputs. But I also don't know if you want octave to read socket or fifo input or not or how you want octave to handle them. You may want to split the case statements that return 0 and only put the st_size check under the S_IFREG condition which would then play nicely with sockets and fifos.

Alternatively, if you really want an iron clad way to check whether anything can be read from stdin, then just make a single call to `read`. This is not ideal though as then you'd have to hold on to whatever you read and hand it off to the script parsing code - not hard certainly, but a bit indirect.

Last edited by Trilby (2018-02-05 22:23:27)

mtmiller · 2018-02-05 22:23:05

@seth, thank you, that is the definition of a closed stdin that I have been assuming.

I am amenable to having octave start its GUI when its stdin is closed, as in that definition.

Trilby wrote:

do you want /dev/null input to behave like an empty file meaning no gui is launched but octave just exits without doing anything

Yes, exactly that.

As to why, because octave is first and foremost an interpreter. Its behavior is analogous to bash or python. When given a file argument, it is interpreted as a script, even when it is empty. When given any input on stdin, it is interpreted as a script, even when it is empty. When stdin is a terminal, then start a REPL.

Trilby · 2018-02-05 22:25:53

Ok, your goals are not what I expected. So you *want* octave to silently fail when told to launch from a window manager menu?

But just the same you're not really meeting the goals:

mtmiller wrote:

As to why, because octave is first and foremost an interpreter. Its behavior is analogous to bash or python.

False. Bash and python don't have guis. Full stop.

When octave is run from a terminal it launches a gui by default! I have to add extra flags to prevent the gui from launching in order to just use the console REPL.

So why do you want the default behavior to act just as an interpreter in all cases except the one single case where it makes the most sense to act just as a REPL interpreter?

Last edited by Trilby (2018-02-05 22:28:34)

Arch Linux

#1 2018-01-25 16:12:02

[Octave] [Openbox] Fails to open when run directly by Openbox

#2 2018-01-25 16:56:40

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#3 2018-01-25 17:12:30

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#4 2018-01-25 17:21:25

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#5 2018-01-25 17:24:37

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#6 2018-01-25 17:56:57

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#7 2018-01-25 18:04:26

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#8 2018-01-25 18:12:53

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#9 2018-01-25 18:43:34

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#10 2018-01-25 18:59:15

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#11 2018-01-25 19:09:29

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#12 2018-01-25 19:16:48

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#13 2018-01-25 19:28:22

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#14 2018-02-02 22:33:52

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#15 2018-02-02 22:43:40

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#16 2018-02-02 23:29:27

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#17 2018-02-03 01:02:10

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#18 2018-02-03 01:51:03

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#19 2018-02-03 10:17:30

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#20 2018-02-05 20:07:14

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#21 2018-02-05 20:39:36

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#22 2018-02-05 21:14:36

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#23 2018-02-05 21:55:56

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#24 2018-02-05 22:23:05

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#25 2018-02-05 22:25:53

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

Board footer