GNU Screen - Can't start if launched on "suckless" simple terminal "st"

joenew · 02-12-2020, 12:19 PM

I use to open a "screen session" under my terminal and all works fine, at least under slackware-14.2 where I have "st" terminal and screen starts without any issues.

On Slackware Current I installed st terminal but if I launch screen, it doesn't return any prompt I can view something like the following (with cursor represented by '|' symbol):

Code:

$ echo $TERM
st-256color
$ screen
|

If I press CTRL+C nothing happens:

Code:

$ echo $TERM
st-256color
$ screen
^C^C^C^C

The only possibility seems CTRL+Z to stop it

Code:

$ echo $TERM
st-256color
$ screen
^C^C^C^C^Z
[1]+  Fermato                 screen
$ pgrep screen
11028
11029
$ pgrep -l screen
11028 screen
11029 screen
$ screen -list
There is a screen on:
        11029.pts-2.localdom      (Dead ???)
Remove dead screens with 'screen -wipe'.
1 Socket in /home/joenew/.screen.

That's what appears: two screen processes and a screen socket likely dead.

I can't figure what is wrong...

If I start screen within an other terminal emulator like for instance "xterm", screen works as usual.
Where could be the issue? How to find it?

Thanks in advance!

business_kid · 02-12-2020, 01:25 PM

Try 'ldd /path/to/screen |grep found' to see are you missing any libs. Have you moved screen or recompiled it? Is there a more recent version? A lot of stuff has altered, as I found out.

joenew · 02-12-2020, 01:51 PM

Code:

'ldd /path/to/screen |grep found'

If something was found, how could it run under xterm?
Anyway let's try:

Code:

$ echo st-256color
st-256color

$ ldd /usr/bin/screen|grep not

$ ldd /usr/bin/screen
        linux-vdso.so.1 (0x00007ffc0f085000)
        libncurses.so.6 => /lib64/libncurses.so.6 (0x00007f5eba692000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f5eba663000)
        libutempter.so.0 => /usr/lib64/libutempter.so.0 (0x00007f5eba460000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f5eba426000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5eba241000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5eba23c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5eba70d000)

The screen package is the one shipped with Slack Current precompiled by Pat.

Code:

/var/log/packages/screen-4.8.0-x86_64-1

I hoped it was due to something wrong in .screenrc, but also moving it to screenrc.bk and let it empty rests in that strange limbic status

joenew · 02-12-2020, 05:46 PM

I recompiled st few days ago after an upgrade of Slack Current packages.
I retried to compile it by hand and noticed this error/warning:

Code:

/st-0.8.2# LANG=en-US.UTF8 make
st build options:
CFLAGS  = -I/usr/X11R6/include  -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DVERSION="0.8.2" -D_XOPEN_SOURCE=600  -O
LDFLAGS = -L/usr/X11R6/lib -lm -lrt -lX11 -lutil -lXft  -lfontconfig -lfreetype  -lfreetype 
CC      = c99
cp config.def.h config.h
c99 -I/usr/X11R6/include  `pkg-config --cflags fontconfig`  `pkg-config --cflags freetype2` -DVERSION=\"0.8.2\" -D_XOPEN_SOURCE=600  -O -c st.c
c99 -I/usr/X11R6/include  `pkg-config --cflags fontconfig`  `pkg-config --cflags freetype2` -DVERSION=\"0.8.2\" -D_XOPEN_SOURCE=600  -O -c x.c
c99 -o st st.o x.o -L/usr/X11R6/lib -lm -lrt -lX11 -lutil -lXft  `pkg-config --libs fontconfig`  `pkg-config --libs freetype2` 
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libutil.so when searching for -lutil
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libutil.a when searching for -lutil
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXft.so when searching for -lXft
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libfontconfig.so when searching for -lfontconfig
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libfreetype.so when searching for -lfreetype
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libfreetype.so when searching for -lfreetype
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libgcc_s.so.1 when searching for libgcc_s.so.1

Is it normal (st binary seems to run regularly after all)?
Or could it hide some issues on some other software in my system?

To test:
From st project site: https://st.suckless.org/
Download the tarball: https://dl.suckless.org/st/st-0.8.2.tar.gz

Code:

tar xvf st-0.8.2.tar.gz
cd st-0.8.2
make

My system is multilib (thanks to AlienBob multilib repo).
Let me know! Thanks in advance!

dugan · 02-12-2020, 10:23 PM

Wildy guessing:

Do you still have the same problem if you export TERM=xterm before starting screen?

joenew · 02-13-2020, 03:49 AM

It seems to solve the issue:

Code:

$ echo $TERM
st-256color

$ export TERM=xterm-256color

$ echo $TERM
xterm-256color

$ screen
[screen is terminating]

$

Anyway st terminal TERM var has to be configured to "xterm-256color", on slackware-14.2 screen works properly from st terminal...
How to let it work also with the st proper TERM value (st-256color)?

joenew · 02-13-2020, 05:17 AM

Wait a moment folks!
Now it seems to work properly even from st terminal... The issue seems disappeared!

Now I can't understand why it didn't work.
I just poweroff yesterday evening and reboot this morning...
Maybe I touch some config yesterday but I can't remember at now

joenew · 02-13-2020, 07:51 AM

Yersterday I edited my xinitrc, to launch xterm at startup instead of st, due to the strange behavior I explained here.
Inside the terminal I launch a screen session.

Look at my xinitrc:

Code:

$ cat .xinitrc
#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f $userresources ]; then
    xrdb -merge $userresources
fi

if [ -f $usermodmap ]; then
    xmodmap $usermodmap
fi

# Start some programs
slstatus &
st -e screen &
#xterm -e screen &

# Start the window manager:
if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then
  exec ck-launch-session /usr/bin/dwm
else
  exec /usr/bin/dwm
fi

Now, if I startx with that startup command (st -e screen &), X starts properly, also st terminal as well as screen session seems running fine.
What's happen if I try to detach that screen session (CTRL+a d) ? Nothing special, screen session results detached... (screen -list)
But when I try to re-attach it (screen -r), well screen crash with this error

Code:

screen caught signal 11. (core dumped)

If I comment "st -e screen &" in xinitrc and uncomment "xterm -e screen &". X startsup, xterm too, as well as screen session.
I can detach it and if I try to reattach it with "screen -r", it works properly.

So something wrong in Simple Terminal seems to persist again.
Any idea is welcome!