bugGNU Octave - Bugs: bug #47449, WARNING: terminal is not fully...

 
 

bug #47449: WARNING: terminal is not fully functionaly

Submitter:  Keith <bollocks>
Submitted:  Fri 18 Mar 2016 12:40:44 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  bollocks Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Mar 2016 06:40:39 PM UTC, comment #14: 

After I correctly applied lachlan's patch to the release candidate it worked.  I will mtmiller's mercurial update now.

Keith <bollocks>
Fri 18 Mar 2016 06:28:47 PM UTC, comment #13: 

I've changed the logic to simply set TERM to either "cygwin" or "xterm" regardless of whether TERM was set in the parent process or not.

Thanks for reporting and testing.

http://hg.savannah.gnu.org/hgweb/octave/rev/c64e57319f08

Mike Miller <mtmiller>
Group Member
Fri 18 Mar 2016 05:55:16 PM UTC, comment #12: 

For the GUI terminal, I guess it should just set the terminal type to xterm if that is what we are providing and if the utilities like less that are supposed to run in it will know what to do with that.

John W. Eaton <jwe>
Group administrator
Fri 18 Mar 2016 05:54:21 PM UTC, comment #11: 

I it was my error in applying the patch to the release candidate that caused it not to work.  It turns out line 167 in the rc corresponds to line 170.  It looks the same but it isn't because 170 in the rc is the if test if the preprocessor detects _WIN32_ is defined. I've attached a file generated by diff for the release candidate.  I'm going to compile the rc with that change now.  The *.patch file was generated with

diff -uNrp oldfile editedfile > .patchfile


I include this because I don't know what the standard is for generating patch files.

(file #36688)

Keith <bollocks>
Fri 18 Mar 2016 05:17:29 PM UTC, comment #10: 

That anonymous comment was me.  I guess I wasn't logged in.  OK can confirm lachan's patch fixes the problem using the code from Mercurial. I'm going to retry with the release candidate code to try to rule out an error on my part when applying the patch.

Keith <bollocks>
Fri 18 Mar 2016 03:41:16 PM UTC, comment #9: 

I applied lachlan's patch to the release candidate and the error still occurred.  Looking at the code I can't think of any reason why.  I'm applying them by hand so there may be an error there, but I double checked the file afterwords so I doubt it.  Is there a way to apply the patch in an automated fashion?  I'm going to try lachlan's patch on the Mercurial code now.

Anonymous
Fri 18 Mar 2016 02:58:24 PM UTC, comment #8: 

Actually looking at this again, I wonder if Octave shouldn't just set TERM=xterm unconditionally. Does it matter if the parent environment had a valid TERM or not? Octave is running its own controlled terminal emulation, so why shouldn't it have exact control over what terminal control sequences are used?

Mike Miller <mtmiller>
Group Member
Fri 18 Mar 2016 02:41:22 PM UTC, comment #7: 

I compiled from the Mercurial source code with mtmiller's patch.  It fixes the problem.  "getenv TERM" returns xterm.  Thanks for the help.  Lachlan, I will try your patch with 4.0.1-rc4 to double check that this type of fix works on the release candidate like it does the Mercurial code.

Keith <bollocks>
Fri 18 Mar 2016 03:44:00 AM UTC, comment #6: 

Installing  xterm  doesn't make a difference.  The TERM variable tells Octave (or other programs) what control codes to use.  As long as your terminal is xterm-compatible, setting TERM=xterm (say in your .bashrc or .cshrc) is enough.

However, you may want to try the attached patch, if Mike's doesn't work.  It explicitly looks for terminal names like xterm-256color and treats them as xterm.

(file #36681)

Lachlan Andrew <lachlan>
Fri 18 Mar 2016 03:31:09 AM UTC, comment #5: 

I tried getenv TERM in Octave.  Under the buggy account I get dumb.  Under the working account I get linux.  I guess that got set because I ran startx from a log in at a getty prompt for that account.

Keith <bollocks>
Fri 18 Mar 2016 03:19:11 AM UTC, comment #4: 

I will try your patch.  I deleted my .ccache folder so it may take a little while to compile Octave again. 

Yes running setenv TERM xterm in Octave solves the problem.  It is not persistent though. 

I checked the launcher file.  There's nothing in there that sets the TERM variable. 


[Desktop Entry]
Name=GNU Octave
Comment=Scientific Computing using GNU Octave
TryExec=/usr/local/bin/octave
Exec=/usr/local/bin/octave --force-gui %f
Icon=/usr/local/share/octave/4.0.1-rc4/imagelib/octave-logo.svg
Terminal=false
Type=Application
Categories=Education;Science;Math;
StartupNotify=false
MimeType=text/x-octave;text/x-matlab;
Keywords=science;math;matrix;numerical computation;plotting;
X-Desktop-File-Install-Version=0.22


I came across something on google that mentioned $TERM before I made the bug report. It also suggested setting it to xterm.  I looked and found there was no xterm on my system.  I installed it using the fedora package manager and it made no difference. 

So I pressed ctrl+alt+f2 and logged in as another user that existed before I installed xterm but had never ran Octave.  Running from the application menu resulted in a functioning terminal with good output.  Seeing that I logged in as root, backed up my home folder, deleted everything, ran userdel, ran useradd same user name, passwd same passwd, and logged in again.  I had to start with the default XFCE configuration like I expected and Octave acted like it had never run before with the welcome screen and stuff.  However running the program from the application menu still resulted in bad help fftw output. 

I double checked and my user ID was 1004 instead of the usual 1000.  The only thing special I can think of with this account is it was created at installation time using Anaconda, which is Fedora's install to disk program.  Otherwise the privileges are the same except the other user doesn't have access to the source and build directories of the octave code.

Also I dragged and dropped the icon from the application menu to the desktop and running it from that no longer fixes the problem.  However running octave from xfce4-terminal does still work.  For what it's worth running echo $TERM returns "xterm-256color" in xfce4-terminal.  My understanding is that xfce4-terminal is a xterm clone with extra features.  It's the default terminal emulator in XFCE4 at any rate.

I'll try your patch and get back to you.

Keith <bollocks>
Fri 18 Mar 2016 01:07:19 AM UTC, comment #3: 

If this is in fact a symptom of how xfce works, something like the attached should fix it. Does it work for you?

(file #36679)

Mike Miller <mtmiller>
Group Member
Fri 18 Mar 2016 12:50:53 AM UTC, comment #2: 

Thanks for the detailed bug report. The TERM environment variable should be set to "xterm" if and only if the inherited environment doesn't already have a TERM set. Does the TERM=dumb value come from the xfce launcher?

By the way, a cleaner way to look at the environment list is


cat /proc/$pid/environ | xargs -0n1 echo | sort


Can you see if your xfce launcher or window manager have TERM=dumb set in their environment?

If you do


setenv TERM xterm


inside the Octave interpreter does that fix the problems you are seeing?

Mike Miller <mtmiller>
Group Member
Fri 18 Mar 2016 12:43:31 AM UTC, comment #1: 

I forgot to mention I'm running Fedora 23 - XFCE spin on a x86_64 laptop.

Keith <bollocks>
Fri 18 Mar 2016 12:40:44 AM UTC, original submission:  

When running Octave from the application menu shortcut created by make install I get an error when I type

help fftw


It says

WARNING: terminal is not fully functional

and when I try to advance the screen using the enter button the (f)orward (b)ack (q)uit menu doesn't get removed from the lines that scroll upward.  Like this:

rentess -- (f)orward, (b)ack, (q)uit
     manners in which the wisdom can be treated:
-- less -- (f)orward, (b)ack, (q)uit
     "estimate"rward, (b)ack, (q)uit
          Specifies that no run-time measurement of the optimal means of(f)orward, (b)ack, (q)uit
          calculating a particular is performed, and a simple heuristic (f)orward, (b)ack, (q)uit
          is used to pick a (probably sub-optimal) plan.  The>> help fftwf)orward, (b)ack, (q)uit


I have tried this using both the code from the Mercurial repository and the release candidate 4.0.1-rc4.  However when I run octave using the ./run-octave program in the build directory or run it from a terminal with the command octave I get the correct output.  If I drag and drop the application menu shortcut to my desktop and double click it I also get the correct output.  I have confirmed that the *.desktop files are identical.  Editing the .desktop file in /usr/local/share/applications so that the Terminal= line is set to true results in a correct output, but also results in an unusable terminal window that kills octave when you kill it. 

This is not limited to help fftw.  It appears to occur any time the less program is called.  For example displaying a large matrix or calling "help plot" also results in the same warning and same type of buggy output.  It also works correctly whenever any of the workarounds mentioned above are tried. 

Looking in the /proc/PID/environ file I can see that there are many additional environment variables associated with a program started with the application menu shortcut(the buggy process):

cat 16414/environ
XDG_VTNR=1XDG_SESSION_ID=3SSH_AGENT_PID=2938GUESTFISH_INIT=\e[1;34mHOSTNAME=localhost.localdomainXDG_GREETER_DATA_DIR=/var/lib/lightdm-data/bollocksIMSETTINGS_INTEGRATE_DESKTOP=yesGLADE_PIXMAP_PATH=:/usr/share/glade3/pixmapsXDG_MENU_PREFIX=xfce-TERM=dumbSHELL=/bin/bashHISTSIZE=1000QTDIR=/usr/lib64/qt-3.3GNOME_KEYRING_CONTROL=/home/bollocks/.cache/keyring-RMVCEYQTINC=/usr/lib64/qt-3.3/includeQT_GRAPHICSSYSTEM_CHECKED=1IMSETTINGS_MODULE=noneUSER=bollocksGLADE_MODULE_PATH=:/usr/lib64/glade3/modulesXDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0SSH_AUTH_SOCK=/tmp/ssh-b591rfTlDVvL/agent.2784GUESTFISH_PS1=\[\e[1;32m\]><fs>\[\e[0;31m\] XDG_CONFIG_DIRS=/etc/xdgMAIL=/var/spool/mail/bollocksDESKTOP_SESSION=xfcePATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/usr/sbin:/usr/local/sbin:/usr/libexec:/usr/local/libexec:/code/bollocks/xms:/home/bollocks/.local/bin:/home/bollocks/binQT_IM_MODULE=ximPWD=/home/bollocksXMODIFIERS=@im=noneLANG=en_US.utf8MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefilesLOADEDMODULES=GUESTFISH_OUTPUT=\e[0mGDMSESSION=xfceSSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpassHISTCONTROL=ignoredupsSHLVL=2XDG_SEAT=seat0HOME=/home/bollocksLOGNAME=bollocksQTLIB=/usr/lib64/qt-3.3/libCVS_RSH=sshDBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-9WL21ZKGAD,guid=d76a9c77b99a969cf770814d56eadb3fXDG_DATA_DIRS=/usr/local/share:/usr/shareMODULESHOME=/usr/share/ModulesLESSOPEN=|/usr/bin/lesspipe.sh %sXDG_RUNTIME_DIR=/run/user/1000GLADE_CATALOG_PATH=:/usr/share/glade3/catalogsXDG_CURRENT_DESKTOP=XFCEGUESTFISH_RESTORE=\e[0mCCACHE_HASHDIR=XAUTHORITY=/var/run/lightdm/bollocks/xauthorityBASH_FUNC_module()=() {  eval `/usr/bin/modulecmd bash $*`
}_=/usr/bin/xfce4-sessionSESSION_MANAGER=local/unix:@/tmp/.ICE-unix/2978,unix/unix:/tmp/.ICE-unix/2978DISPLAY=:0.0[


vs a non buggy process

cat 16442/environ
SHELL=/bin/bashXDG_CURRENT_DESKTOP=XFCEXDG_RUNTIME_DIR=/run/user/1000XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0DESKTOP_SESSION=xfceXDG_GREETER_DATA_DIR=/var/lib/lightdm-data/bollocksPATH=/usr/local/bin:/usr/bin:/binGDMSESSION=xfceXDG_VTNR=1XDG_SESSION_ID=3DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-9WL21ZKGAD,guid=d76a9c77b99a969cf770814d56eadb3fXDG_SEAT=seat0XAUTHORITY=/var/run/lightdm/bollocks/xauthorityUSER=bollocksXDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0SHLVL=1GDM_LANG=en_US.utf8PWD=/home/bollocksGNOME_KEYRING_CONTROL=/home/bollocks/.cache/keyring-RMVCEYLANG=en_US.utf8_=/usr/bin/dbus-launchLOGNAME=bollocksHOME=/home/bollocksDISPLAY=:0.0


At this point I'm over my head.

Keith <bollocks>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #36688:  octave-gui.cc.patch added by bollocks (543B - text/x-patch)
file #36681:  bug_47449_terminal.cset added by lachlan (993B - text/x-diff)
file #36679:  term.diff added by mtmiller (447B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by bollocks (Submitted the item)
  • -email is unavailable- added by bollocks
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-18 mtmiller StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2016-03-18 bollocks Attached File- Added octave-gui.cc.patch, #36688
    2016-03-18 lachlan Attached File- Added bug_47449_terminal.cset, #36681
    2016-03-18 mtmiller Attached File- Added term.diff, #36679
    2016-03-18 mtmiller StatusNone Need Info
    2016-03-18 bollocks Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code