Как они реализуют этот процесс восстановления?
Они этого не делают. Это не их дело.
Это так называемый буфер альтернативного экрана , который включается и выключается. Это реализовано в самом терминале (или программе-эмуляторе терминала). Терминал реагирует на управляющие последовательности, которые излучаются такими программами TUI. Программы TUI управляют , когда это происходит, но реализация того, что происходит , полностью находится внутри терминала. Действительно, программы TUI даже не имеют той же модели того, что происходит. Для них они переключаются в «режим адресации курсора» и выходят из него.
Не все терминалы и программы-эмуляторы терминала имеют даже альтернативный экранный буфер. Например: программы эмулятора терминала, встроенные в ядра Linux и BSD, которые предоставляют свои виртуальные терминалы ядра, обычно не имеют этой возможности.
На таких клеммах отсутствует управляющая последовательность. Следовательно, запись в базе данных termcap / terminfo для типа терминала не будет иметь такой управляющей последовательности; и переключение в «режим адресации курсора» и из него перезаписывает текущее содержимое экрана без сохранения и восстановления его.
vim, nano и тому подобное ничего об этом не знают . Они не делают ничего другого. Они не то, что выполняет функцию. Они просто испускают управляющие последовательности, которые, как сообщает им termcap / terminfo, войдут и выйдут из «режима адресации курсора». Для некоторых терминалов, имеющих такой механизм, «режим адресации курсора» также означает использование альтернативного экранного буфера .Для некоторых это не так.
Дополнительная литература
Я провел небольшое расследование и пришел к выводу, что есть две причины, по которым скрипты с источниками в .profile
не работают:
Когда вы открываете новый сеанс терминала, bash запускается как интерактивная оболочка без входа -. Поскольку .profile
запускается только для не -интерактивной оболочки входа в систему, запуск сеанса терминала не запускает ее.
Хотя сценарий создается при входе в систему с помощью .profile
, в отличие от переменных среды PATH , которые экспортируются в дочерние процессы при входе в систему, если они установлены в .profile
, источником является команда и не может быть экспортирована в дочерние процессы, запущенные из первого экземпляра bash, инициализированного при входе в систему. Другими словами, source
является интерактивным и должен находиться в .bashrc
, который является единственным стартовым -up-файлом, который запускается в интерактивной оболочке без входа -.
TL;DR .profile
вызывает сценарий только один раз при входе в систему и не передается в среду сеанса терминала. Следовательно, я получил сценарий, поместив его в .bashrc
.
Чтобы ответить на вопросы выше, у меня нет ~/.bash_profile
и в.profile
Бонус:По этим причинам я предполагаю, что псевдоним, установленный в .profile
, также не будет работать, поскольку это команда, которую необходимо выполнять каждый раз, когда в окне терминала создается новая среда.
Изman bash
(упор мой):
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
Вероятно, у вас есть ~/.bash_profile
, как сказал jasonwryan, поэтому ваш ~/.profile
никогда не читается. Этот ответ предполагает поиск ~/.profile
в вашем ~/.bash_profile
. Вы можете сделать это, или вместо этого вы можете найти свой исполняемый скрипт в ~/.bash_profile
.
См. также Онлайн-руководство по Bash .