Экран GNU: Странный TERMCAP при использовании-d-m

Определения локали поднимают большое дисковое пространство (при складывании всех различных локалей, которые доступны), таким образом, Debian и другие дистрибутивы генерируют их по запросу. На Debian, выполненном dpkg-reconfigure locales (как корень), и выбирают локали, которыми Вы интересуетесь. Удостоверьтесь, что установили флажок для en_US.utf8 (и другой en_US варианты, в то время как Вы в нем). Кроме того, некоторые категории странно объявляются как en_gb; ищите строку en_gb в Ваших конфигурационных файлах (grep -r en_gb ~/.[!.]* /etc) и зафиксируйте незаконный файл.

3
10.03.2013, 07:36
2 ответа

Когда вы используете опции -d -m, screen запускается в режиме detached, и в этом случае не пытается улучшить описание терминала на основе вашей текущей TERM переменной. Он ищет вашу переменную TERM только при обычном запуске (не отсоединенном). Когда вы подключаетесь к сессии, которая была запущена в отсоединенном состоянии, уже слишком поздно делать эту инициализацию на основе TERM.

В разделе 16.1 Выбор записи termcap для окна в руководстве описаны некоторые исправления.

То, что вы видели для нерабочего случая, выглядит так:

TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
        :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
        :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
        :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
        :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
        :li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
        :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
        :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
        :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
        :ti=\E[?1049h:te=\E[?1049l:k0=\E[10~:k1=\EOP:k2=\EOQ:\
        :k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\
        :k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\
        :kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\
        :kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:

в то время как хороший случай выглядит так:

TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
        :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
        :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
        :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
        :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
        :li#25:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
        :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
        :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
        :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
        :ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
        :se=\E[23m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\
        :Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:G0:\
        :as=\E(0:ae=\E(B:\
        :ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
        :k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
        :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
        :F1=\E[23~:F2=\E[24~:kb=^H:K2=\EOE:kB=\E[Z:kh=\E[1~:\
        :@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:kI=\E[2~:\
        :kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:km:

В хорошем случае screen заметил, что TERM установлен в xterm, и добавил возможности из этого описания.

Вы заметите эту проблему на FreeBSD, потому что termcap, распространяемый с screen, не имеет цвета, когда вы ограничиваете описание 1023-байтным лимитом, предполагаемым приложениями termcap (дополнительные параметры отбрасываются). На других платформах вы, скорее всего, будете использовать описание, предоставляемое ncurses, которое делает указание, как использовать цвет. Разница не связана с используемой библиотекой; хотя screen является termcap-приложением, на FreeBSD он использует ncurses:

$ ldd `which screen`
/usr/local/bin/screen:
    libncurses.so.8 => /lib/libncurses.so.8 (0x80086a000)
    libelf.so.1 => /usr/lib/libelf.so.1 (0x800ab6000)
    libutil.so.9 => /lib/libutil.so.9 (0x800ccb000)
    libulog.so.0 => /lib/libulog.so.0 (0x800edd000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x8010df000)
    libc.so.7 => /lib/libc.so.7 (0x8012ff000)
    libmd.so.6 => /lib/libmd.so.6 (0x801698000)

Вместо этого, разница связана с тем, что

  • FreeBSD собирает ncurses, используя базу данных termcap в предпочтении к terminfo (вы можете получить базу данных terminfo через порт), и
  • FreeBSD имеет файл termcap, который не соответствует другим терминальным базам данных. Хотя некоторые исправления были сделаны, она все еще имеет причуды, такие как VT100s с цветом, и модификации, чтобы сделать различия между консолью с TERM=xterm и настоящим xterm менее очевидными (кроме людей, использующих xterm, конечно).

По некоторой иронии судьбы можно заметить, что screen устанавливает TERMCAP в многострочный формат. Этот формат использовался в 4.2BSD и 4.3BSD, но устарел в 4.4BSD (около 25 лет назад), с переходом на использование хэшированных баз данных и одновременным удалением пробельных символов (которые учитывались в ограничении на размер termcap в 1023 байта). Поскольку FreeBSD перешла на использование ncurses в 1990-х годах, этот формат более устарел, и лишь немногие приложения полагаются на переменную TERMCAP. Но ls - одно из них.

screen имеет опцию -T, которая должна помочь с этим, указывая конкретную запись termcap (которая имеет цвет), но при тестировании оказалось, что это не может решить проблему.

Дополнительная литература:

2
27.01.2020, 21:20

Ну, я заставил что-то не слишком грубое устранять проблему:

В моем сценарии, где я создаю screen сессии, я имею около вершины:

# This runs the commands:
# TERM=screen
# TERMCAP='...'
# with values appropriate for a 'screen' terminal
eval "$(tset - -s screen | tail -n+2)"

# Set up the SCREENCAP variable, which 'screen' will use for new sessions
SCREENCAP="$TERMCAP"; export SCREENCAP

# ...

screen -d -m -S my-session

Теперь, когда я соединяюсь с my-session, терминал окрашивает работу.

Не совсем удовлетворительный, но работы достаточно хорошо.

2
27.01.2020, 21:20

Теги

Похожие вопросы