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

 
 

bug #47449: WARNING: terminal is not fully functionaly

Submitted by:  Keith <bollocks>
Submitted on:  Fri 18 Mar 2016 12:40:44 AM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: None
Originator Name: bollocksOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
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>
Project 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

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>
Project Administrator
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>
Project Member
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.

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>
Project Administrator
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

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

If you do

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

Mike Miller <mtmiller>
Project Administrator
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

It says
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:

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):

vs a non buggy process

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 File(s):
   
   
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
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lachlan (Updated the item)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by bollocks (Submitted the item)
  • -unavailable- added by bollocks
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 18 Mar 2016 06:28:47 PM UTCmtmillerStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
    Fri 18 Mar 2016 05:54:21 PM UTCbollocksAttached File-=>Added octave-gui.cc.patch, #36688
    Fri 18 Mar 2016 03:44:00 AM UTClachlanAttached File-=>Added bug_47449_terminal.cset, #36681
    Fri 18 Mar 2016 01:07:19 AM UTCmtmillerAttached File-=>Added term.diff, #36679
    Fri 18 Mar 2016 12:50:53 AM UTCmtmillerStatusNone=>Need Info
    Fri 18 Mar 2016 12:40:44 AM UTCbollocksCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1