[Octave-bug-tracker] [bug #53034] Octave GUI fails to open when stdin closed. Patch included

[Mike Miller]

Follow-up Comment #11, bug #53034 (project octave):

I am attaching a new patch that applies to both default and stable. This patch
adds a more exhaustive set of checks on standard input, almost exactly as has
been suggested by our friends on the Arch forums. Octave checks whether its
standard input is open and valid, is a terminal, or is a regular file, pipe,
socket, or character stream. The only change I made was the inclusion of
character devices as valid inputs.

There is also plenty of debug output to show what checks are being performed
and what the results are. Octave also queries the proc filesystem to try to
determine what the file name of its input is.

I have tested this patch while attempting to run octave without the
--force-gui option from various graphical launcher tools in the GNOME desktop,
the i3 window manager, and the Openbox window manager.

In all cases I have tested, Octave without --force-gui does not start. So this
additional checking has no practical effect. The debugging will hopefully
demonstrate why.

In the GNOME desktop, running from either a .desktop file launcher or from the
Alt+F2 "run something" prompt, the following is reported to the gnome session
log:


DEBUG: is_readable_input: /proc/self/fd/0 -> /dev/null
DEBUG: is_readable_input -> true: is a valid input file type


In the Openbox window manager, running Octave from an openbox-menu custom
entry, the following is shown in the session log:


DEBUG: is_readable_input: /proc/self/fd/0 -> /dev/null
DEBUG: is_readable_input -> true: is a valid input file type


The same is reported when I run octave from the 'gmrun' command line launcher,
as used by the original poster on the Arch forums.

In the i3 window manager, running Octave from the 'dmenu' launcher/menuing
system, the following is shown in the session log:


DEBUG: is_readable_input: /proc/self/fd/0 -> pipe:[2152967]
DEBUG: is_readable_input -> true: is a valid input file type


This difference is because dmenu executes a command by echoing the command
line to the user's shell for shell interpolation. In this situation, octave
inherts the standard input of bash, which is the pipe from the echo command.
The same can be reproduced with


$ echo octave | bash
DEBUG: is_readable_input: /proc/self/fd/0 -> pipe:[2547526]
DEBUG: is_readable_input -> true: is a valid input file type


Under GNOME and Openbox, running 'octave' from a menu entry, graphical
launcher, .desktop shortcut, all are indistinguishable from running octave as


$ octave < /dev/null


Using dmenu in the i3 window manager, running 'octave' is indistinguishable
from running octave as


$ echo octave | bash


I don't have enough tuits at the moment to test more window managers, but I
would be interested to see the results if others are willing to build octave
with this patch and test under their favorite WM or DE.

So far I have not seen a situation where octave is started with its standard
input closed.

(file #43179)
    _______________________________________________________

Additional Item Attachment:

File name: octave-gui-stdin-logic.patch   Size:2 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53034>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/