xfce4-terminal change (problem) in Xubuntu 18.10

cjsmall · 2019-02-06 05:07:20

I launch a number of programs such as the nn(1) news reader or mutt(1) mail reader in an xfce4-terminal as follows:

xfce4-terminal -T Mutt Mail --geometry 80x34+938+0 --display=:0.0 --color-bg=#EDF4F0 -e /usr/bin/mutt

This has worked fine in all version of Xubuntu up through 18.04. After upgrading to 18.10, the program (mutt or nn) no longer understand the size of the terminal. Despite giving it a geometry of 34 lines, the programs default to a 24-line terminal and will not use the remaining available space. Furthermore, when you manually resize the terminal window, the program does not get signaled and resize as they always previously did.

Something was apparently done to the terminal code that affects the LINES and COLUMNS handling.

Is this a known problem and is there a workaround?

Thanks.

Skaperen · 2019-02-06 07:35:44

what does the command "stty -a|grep li" tell you the size is?

what does the command "env|egrep -i ^.o.s=" tell you the size is?

i don't know of the problem. i'm running 16.04 so i won't see it if it's a thing in 18.10. it could be a problem in mutt and nn or one of the libraries they use. more experiments and tests may be needed to pin it down. i hope to see if other programs have the issue.

Last edited by Skaperen (2019-02-06 07:43:27)

cjsmall · 2019-02-06 07:50:14

I'm firing up an xfce4-terminals with the command: xfce4-terminal --geometry 80x34+938+0

# stty -a|grep li
speed 38400 baud; rows 34; columns 80; line = 0;

# env|egrep -i ^.o.s=
[no output]

What actual environment variable are you looking for with the second command?

cjsmall · 2019-02-06 08:08:48

Here is some more information that may or may not be relevant.

When I have an existing xfce4-terminal in place and I run the nn or mutt commands there, they recognize the terminal size properly and will also respond correctly to resizing the window. The problem only manifests when I attempt to launch a new terminal and specify the command using -e as shown in the original post. When the command is executed in the new terminal, it doesn't pick up the actual size.

Also:

I am having some xfce4 desktop issues since upgrading to 18.10. I have two monitors and always ran separate desktop managers on each screen. This broke during the upgrade and I cannot get a proper desktop environment on display :0.1. If interested, you can read more here:

https://mail.xfce.org/pipermail/xfce/20 … 36275.html

I have a proper desktop running on display :0.0 and have been able to launch Firefox and a couple of xfce4-terminals on display :0.1, but only by setting the DISPLAY variable before the command. For example:

(DISPLAY=:0.1 xfce4-terminal --geometry 80x33+0+47 >/dev/null 2>&1 &)

However, the --display=:0.0 or --display=:0.1 options are being ignored by all commands. Once I've placed anything on display :0.1, when I launch the command as in my original post with --display=:0.0, the terminal still ends up on display :0.1.

All of this is probably related, but I'm unclear as to what fundamentally changed in Xfce4 to create these problems.

ToZ · 2019-02-06 11:39:58

The version of xfce4-terminal shipped with 18.10 uses vte3. I can replicate the xfce4-terminal issue using mutt. You should create bug reports at the bug trackerfor both the xfce4-terminal and the xfdesktop issues. You may get more traction there.

cjsmall · 2019-02-06 16:50:59

Thanks ToZ. I've created a bug report for the desktop issue. I will do the same for the terminal emulator.

Reported terminal problem here:

https://bugzilla.xfce.org/show_bug.cgi?id=15125

Reported desktop problem here:

https://bugzilla.xfce.org/show_bug.cgi?id=15116

Last edited by cjsmall (2019-02-06 17:24:19)

Skaperen · 2019-02-06 18:35:13

in the 2nd one i am expecting

lt2a/forums /home/forums 1> env|egrep -i ^.o.s=
COLS=172
ROWS=46
lt2a/forums /home/forums 2>

and the full set of possible variables is

lt2a/forums /home/forums 2> env|egrep '172|46'
COLS=172
COLUMNS=172
LINES=46
ROWS=46
lt2a/forums /home/forums 3>

though i think the first two are standard. those are what i used in my code to create detached screen sessions with copied or specified geometry (a system i use to run stuff in the background, even if it needs a terminal).

cjsmall · 2019-02-06 20:00:47

In the xfce4-terminal, $ROWS and $COLS are undefined, but $LINES and $COLUMNS are set to the appropriate values.

If I launch the terminal setting ROWS and COLS as in:

(ROWS=311 COLS=80 xfce4-terminal -T 'NN_News_Reader' --geometry 80x31+${X}+0 --color-bg='#EDF4F0' -e 'nn' &)

this does not correct the situation. nn still defaults to 24 rows.

Skaperen · 2019-02-07 03:57:27

since stty reports 34 rows. the virtual terminal itself is set right. you can strace stty to see what syscalls it does. this information is stored in the kernel for the controlling tty. it's the environment that is not set right. you could add code to your .bashrc file to get the data from stty and set the environment variables. i have been doing that in my .bashrc file for a couple decades.

starting at line 512 in my .bashrc file:

#-------------------------------
# get and export terminal sizes.
#-------------------------------
# usually, stty has the sizes
rows=$(stty -a|fgrep rows|cut '-d;' -f2|cut '-d ' -f3)
cols=$(stty -a|fgrep rows|cut '-d;' -f3|cut '-d ' -f3)
# if stty does not have the sizes then try environment variables
dostty=''
if [[ "$rows" = 0 && "$LINES" != 0 ]];then
    rows="$LINES"
    dostty=yes
fi
if [[ "$cols" = 0 && "$COLUMNS" != 0 ]];then
    cols="$COLUMNS"
    dostty=yes
fi
[[ -z "dostty" ]]||stty cols "$cols" rows "$rows"
export ROWS="${rows}"
export COLS="${cols}"
export LINES="${rows}"
export COLUMNS="${cols}"

that code also works in reverse so i can set the size of background virtual terminals in a newly created screen session using environment variables so that screen and the background virtual terminal will be in agreement (screen needs to know the size to store the buffer correctly but only has two sizes it can set things to if it does the setting. getting a detached screen to have the size i wanted required juggling a couple screen sessions.

cjsmall · 2019-02-07 05:46:36

Here is an update. Over on bugzilla (https://bugzilla.xfce.org/show_bug.cgi?id=15125) we have also been exploring this problem and discovered the following:

I have a script called nn_run that launches nn in the terminal. It executes the following command:

xfce4-terminal -T 'NN_News_Reader' --geometry 80x31+${X}+0 --color-bg='#EDF4F0' -e nn &

it was discovered that if you make a new script called nnx with this simple content:

#!/bin/ksh
nn

And call this rather than nn directly as follows:

xfce4-terminal -T 'NN_News_Reader' --geometry 80x31+${X}+0 --color-bg='#EDF4F0' -e nnx &

Then the size of the resulting terminal will be recognized by nn! There is some sort of initialization problem when using the -e option, but this level of indirection allows nn to properly discover the terminal size. So I think this pretty definitely proves that the xfce4-terminal code is doing something wrong in the handling of its argument. However, if this triggers any other thoughts, please share them here or on the bugzilla page.

I haven't previously run into problems with not having ROWS and COLS set, but your suggestion is a good one to be on the safe side. I'll add this to my .kshrc file as I use ksh as my default shell.

Skaperen · 2019-02-07 07:21:02

"ps awx|grep nn" might show you what arguments got passed to "nn". you could see the command line if you get the PID with the command "tr '\0' '\040' </proc/$PID/cmdline;echo". it would be interesting to see if "--geometry ..." gets passed along right, or lost, or mangled. while xfce4-terminal could be setting up the tty wrong, my sense is that there is a problem with nn and mutt. and the reason is that the resize is also broken. while xfce4-terminal could be broken in this regard, i see general apps break on this quite often. if this were happening to me, i'd be looking real close at what geometry info is being passed along and try to pin that down in fine detail. i'd be testing with non-X text editors (or just unset DISPLAY for emacs).

i just got started on Xfce over the past few weeks. it looks like i need to dive down into developer or systems level soon with Xfce (i have been programming in C since 1982). and xfce4-terminal happens to already hold much interest.

Skaperen · 2019-02-07 07:25:05

i don't know how much of my script code will work in ksh. the "[[" and "]]" might not. i understand that bash added them internally a long time ago. i do most of my script coding in Python, now.

cjsmall · 2019-02-07 14:42:22

[[ ]] works fine in ksh. I think this is actually where they were first introduced. I've been using the Korn shell since the mid to late 80s.

cjsmall · 2019-02-07 19:07:13

Another more direct way to get cols and lines is using tput:

rows=$(tput lines)
cols=$(tput cols)

I also see that:

stty size

outputs just the lines and columns, making parsing easier.

Skaperen · 2019-02-08 09:28:41

if they work in ksh, great (i didn't need to warn about them). nice to know about stty size.

Xfce Forum

Sub domains

#1 2019-02-06 05:07:20

xfce4-terminal change (problem) in Xubuntu 18.10

#2 2019-02-06 07:35:44

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#3 2019-02-06 07:50:14

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#4 2019-02-06 08:08:48

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#5 2019-02-06 11:39:58

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#6 2019-02-06 16:50:59

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#7 2019-02-06 18:35:13

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#8 2019-02-06 20:00:47

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#9 2019-02-07 03:57:27

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#10 2019-02-07 05:46:36

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#11 2019-02-07 07:21:02

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#12 2019-02-07 07:25:05

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#13 2019-02-07 14:42:22

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#14 2019-02-07 19:07:13

Re: xfce4-terminal change (problem) in Xubuntu 18.10

#15 2019-02-08 09:28:41

Re: xfce4-terminal change (problem) in Xubuntu 18.10

Board footer