Процесс, запущенный скриптом не получает SIGINT

В tmux FAQ есть некоторая информация о поддержке 256 цветов.

Определение количества цветов, поддерживаемых терминалом, к сожалению, не является простым, по историческим причинам. Смотрите Проверка количества цветов, поддерживаемых моим эмулятором терминала для объяснения. Это означает, что

  • tmux не может надежно определить, поддерживает ли терминал более 8 цветов;
  • tmux не может надежно сообщить приложению, что оно поддерживает более 8 цветов.

Когда вы находитесь в tmux, терминал, с которым вы взаимодействуете, - это tmux. Он не поддерживает все управляющие последовательности xterm. В частности, он не поддерживает управляющую последовательность OSC 4 ; ... для запроса или установки значений цвета. Вы должны использовать ее при непосредственном запуске в xterm, вне tmux.

Если вы запустите tmux -2, то tmux запустится с поддержкой 256 цветов, даже если он не думает, что ваш терминал поддерживает 256 цветов (что бывает довольно часто).

По умолчанию tmux рекламирует себя как screen без поддержки 256 цветов. Вы можете изменить значение TERM в .tmux.conf, чтобы указать поддержку 256 цветов:

set -g default-terminal "screen-256color"

Вы можете использовать TERM=xterm-256color или TERM=screen-256color на Ubuntu. Эти значения вызовут проблемы, только если вы войдете на удаленную машину, на которой нет записи termcap/terminfo для этих имен. Вы можете скопировать записи в свой домашний каталог на удаленной машине; это работает с большинством современных реализаций terminfo.

# From the Ubuntu machine to a machine that doesn't have *-256color terminfo entries
ssh somewhere.example.com mkdir -p .terminfo/s .terminfo/x
scp -p /lib/terminfo/s/screen-256color somewhere.example.com:.terminfo/s/
scp -p /lib/terminfo/x/xterm-256color somewhere.example.com:.terminfo/x/

1
03.12.2018, 10:13
1 ответ

Нет, они начинаются по-разному. Поскольку bash запускает сценарии с отключенным управлением заданиями, фоновый режим команд, запускаемых с помощью&из сценария , просто «подделывается», позволяя им игнорировать SIGINT и SIGQUIT и перенаправляя их ввод из /dev/null.

См. мой ответ здесь (со ссылками на стандарт, описывающий это ).

В вашем случае это также означает, что main.pyне устанавливает никакого обработчика для SIGINT, чтобы выполнить «изящный» выход, но он просто принудительно уничтожается с помощью Control -C или kill -2, когда запускать из интерактивной оболочки. Если бы он установил обработчик, этот обработчик также переопределил бы расположение SIG_IGNSIGINT, установленное родительской оболочкой при запуске из сценария.

3
27.01.2020, 23:31

Теги

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