Терминалы, консоли, эмуляторы терминалов, оболочки

[sunny1983]

Как не перепутать между собой термины, указанные в заголовке.

Начну с того что знаю. tty-устройства берут своё начало с телетайпов, во времена когда компьютеры были большими. В те времена для ввода и вывода данных использоватись терминалы. В Linux имеется шесть виртуальных терминалов /dev/tty1 - /dev/tty6. /dev/tty0 означает текущий виртуальный терминал, не него выводят свои сообщения ядро и демоны. Также в компьютере имеются COM-порты /dev/ttyS0 и /dev/ttyS1, которых с виртуальными терминалами объединяет то, что и те, ите являются устройствами последовательностного доступа. А вот для чего нужны все остальные tty в /dev, их там около шестидесяти? Это первый вопрос.

Виртуальные терминалы стартуют во время выполнения самого первого конфигурационного файла /etc/inittab:

Код: Выделить всё

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

После того как ядро и демоны закончат выводить свои сообщения в терминал и процесс загрузки Linux будет завершён, getty выведет на терминал приглашение ввести логин и пароль.
Вопрос 2 (очень давно меня интересует): возможно ли то что выводится в терминал записывать в лог?

После залогинивания запустится оболочка (по умолчанию bash), в которой мы и будем работать. Правда перед этим она отработает конфиги profile и bashrc.
Ещё есть эмуляторы терминалов. Продвинутые линуксойды рекомендуют использовать screen, дескать он повышает удобство работы в командной строке.
А вот командой tty я могу узнать в каком терминале я сейчас нахожусь. Если до запуска screen я находился в /dev/tty1, то теперь говорит, что я в /dev/pts/0 Как это понимать? Где должен запускаться screen в bashrc или можно прописать непосредственно в /etc/inittab и как должна выглядеть строка для его запуска. Маны по параметрам запуска screen читал, но ничего не понял, сказано что он умеет подключаться к уже существующим открытым терминалам.
При запуске screen я теряю содержимое активного экрана, можно ли настроить так, чтобы этого не происходило?

[Yaros]

Вопрос 2 (очень давно меня интересует): возможно ли то что выводится в терминал записывать в лог?

Погуглите "LiLaLO" или ttyrec.
А так же почитайте про stdout и stderr.
И желательно объяснить подробнее, что значит "записывать в лог".

[alv]

Как не перепутать между собой термины, указанные в заголовке.

Как-то вот так: http://fossbook.info/subprojetcs/shell

[Hephaestus]

Вопрос 2 (очень давно меня интересует): возможно ли то что выводится в терминал записывать в лог?

Оно и так записывается. По крайней мере в Debian. Смотрите содержимое каталога /var/log. Там куча всяких логов.
Плюс к этому ведение логов настраивается у различных программ, например, iptables.

Запись в лог может и не произойти, например, если вдруг становится недоступен /var/log из-за отказа диска. В этом случае ошибки на экране будут, а в логе нет.
Или, скажем, в случае паники ядра. Лог писать просто некому.
Это я на тот случай, если есть подобная проблема, а в логах не отразилось. Нужно понимать, почему.

[t.t]

Вопрос 2 (очень давно меня интересует): возможно ли то что выводится в терминал записывать в лог?

Оно и так записывается. По крайней мере в Debian.

Неверно. Далеко не всё, что выводится в терминал, по умолчанию пишется в какие-либо логи.

[Hephaestus]

Неверно. Далеко не всё, что выводится в терминал, по умолчанию пишется в какие-либо логи.

Пример можно?
сообщения ядра пишутся в kernel.log
сообщения об ошибках в errors
syslog тоже не дремлет.
А есть ещё и messages.
Эти логи по-моему, покрывают процентов 90 того, что выводится в терминал.
Программы типа aptitude или X-сервер имеют свои логи, и некоторые другие программы тоже.

Что же там такого в терминал выводится, что не попадает в один из вышеуказанных логов?
Ну разве что сообщения типа вывода программы dd: "столько-то блоков записано", но такие логи настраиваются на уровне самих программ, как у iptables, wget, lm-sensors... Для них, понятное дело. по умолчанию, лог не ведется - бессмысленно, если программа не установлена.

А если программа типа iceweasel запускается из терминала и пишет туда какие-то сообщения, то они попадают в один из указанных логов, если не ошибаюсь.
А вообще, надо уточнить, вопрос интересный.

[sunny1983]

сообщения ядра пишутся в kernel.log
сообщения об ошибках в errors
syslog тоже не дремлет.
А есть ещё и messages.
Эти логи по-моему, покрывают процентов 90 того, что выводится в терминал.
Программы типа aptitude или X-сервер имеют свои логи, и некоторые другие программы тоже.

Вопрос то по другому задан. Ядро, демоны и программы пишут в консоль и в логи. Но вопрос о том как логировать саму консоль, писать в логи сообщения всех кто туда пишет, в том числе пользователей.

[Hephaestus]

Вопрос то по другому задан. Ядро, демоны и программы пишут в консоль и в логи. Но вопрос о том как логировать саму консоль, писать в логи сообщения всех кто туда пишет, в том числе пользователей.

То есть логировать вообще всё? Вплоть до команд, вводимых пользователем?
Типа такого:
Пользователь вводит

Код: Выделить всё

$date

В ответ получает

Код: Выделить всё

$Срд Окт 3 09:26:59 SAMT 2012

И в логе должно отразиться

Код: Выделить всё

date
Срд Окт 3 09:26:59 SAMT 2012

Я правильно понял мысль?
Если да, то честно скажу: способа такого не знаю.
Навскидку: для этого надо дублировать в файл не только stdout и stderr, как выше уже упоминали, но ещё и stdin.
А вот можно ли это сделать, я сказать не могу.
Этакая система наблюдения, когда всё, вводимое на одной машине, отражается на другой...
Где-то в кино такое видел, но как это сделать, не знаю.



А можно узнать, зачем Вам это? Если, конечно, не секрет.
Про логи ядра и программ, я уже писал, а команды, вводимые пользователем, сохраняются в history.
Для большинства задач этого достаточно.


UPD: Нагуглилась команда script, похоже делает как раз то, что Вам нужно.

[drBatty]

Вопрос 2 (очень давно меня интересует): возможно ли то что выводится в терминал записывать в лог?

эх...
вот, прочитайте

SCRIPT(1) User Commands SCRIPT(1)

NAME
script - make typescript of terminal session

SYNOPSIS
script [options] [file]

DESCRIPTION
script makes a typescript of everything printed on your terminal. It is useful for students who need a
hardcopy record of an interactive session as proof of an assignment, as the typescript file can be printed
out later with lpr(1).

If the argument file is given, script saves all dialogue in file. If no file name is given, the type‐
script is saved in the file typescript.

оно?

Ещё есть эмуляторы терминалов. Продвинутые линуксойды рекомендуют использовать screen, дескать он повышает удобство работы в командной строке.

используя screen вы можете в любой момент разорвать соединение, и через произвольное время вернуться на сервер, как нивчём небывало. Вобщем-то для того она и нужна. Если у вас локальный терминал, использование screen не столь полезно, однако, есть ещё 2 случая:
1. можно запустить какую-то ОЧЕНЬ долгую программу, и иногда смотреть, как она там?
2. можно работать в одном и том же терминале вместе с каким-то гуру(или наоборот с нубом) и учиться(учить)

Правда перед этим она отработает конфиги profile и bashrc.

неа. .bashrc НЕ отработает. При логине работает ~/.bash_login, а вот если запустить bash (из bash'а например), сработает .bashrc. man bash.

При запуске screen я теряю содержимое активного экрана, можно ли настроить так, чтобы этого не происходило?

не нужно (С) ЛОР

[sunny1983]

Если да, то честно скажу: способа такого не знаю.
Навскидку: для этого надо дублировать в файл не только stdout и stderr, как выше уже упоминали, но ещё и stdin.
А вот можно ли это сделать, я сказать не могу.

Понятно, такого способа не существует. Спасибо за ответ, отрицательный ответ тоже ответ.
Я спрашивал потому, что мне казалось, что в Linux такая система есть по умолчанию. А надобность, так это просто для того чтобы пользователь мосмотреть свою собственную историю работы в консоли.

используя screen вы можете в любой момент разорвать соединение, и через произвольное время вернуться на сервер, как нивчём небывало. Вобщем-то для того она и нужна. Если у вас локальный терминал, использование screen не столь полезно, однако, есть ещё 2 случая:
1. можно запустить какую-то ОЧЕНЬ долгую программу, и иногда смотреть, как она там?
2. можно работать в одном и том же терминале вместе с каким-то гуру(или наоборот с нубом) и учиться(учить)

Да, да, да, только пока не соображу как это настроить, хотя в инете много об этом написано

неа. .bashrc НЕ отработает. При логине работает ~/.bash_login, а вот если запустить bash (из bash'а например), сработает .bashrc. man bash.

~/.bash_login текущего пользователя сработает, а что касается глобального файла /etc/bash.bashrc?
Я в конце /etc/bash.bashrc добавил screen - теперь при залогинивании запускается bash из которого запускается screen, который в свою очередь запускает bash, такой вот слоёный пирог получается.
В некоей статье написано, что в bashrc нужно добавлять

Код: Выделить всё

if [ -z "$STY" ]; then
     exec screen -dR
fi

В этом случае у меня сразу после залогирования сразу же проиходит detach

не нужно (С) ЛОР

Как это не нужно? При запуске screen я теряю то, что было на экране до него, а там может быть куча полезного, например сообщение о пришедшей почте, которое выводится сразу после залогинивания.

[Hephaestus]

Понятно, такого способа не существует. Спасибо за ответ, отрицательный ответ тоже ответ.
Я спрашивал потому, что мне казалось, что в Linux такая система есть по умолчанию.

Ну почему же не существует?
Я сказал, что не знаю, это не значит, что не существует.
Чуть позже нагуглилась программа script. О чем я и написал ниже под меткой UPD.
А ещё ниже
drBatty тоже о ней написал.
Читайте чуть внимательнее.

[drBatty]

Понятно, такого способа не существует. Спасибо за ответ, отрицательный ответ тоже ответ.

блжд! man script

Да, да, да, только пока не соображу как это настроить, хотя в инете много об этом написано

что там настраивать-то? берёте и запускаете. другое дело, что вам это похоже не нужно, а нужно man script.

~/.bash_login текущего пользователя сработает, а что касается глобального файла /etc/bash.bashrc?

читаю маны. вслух. с выражением. ДОРОГО.

Я в конце /etc/bash.bashrc добавил screen - теперь при залогинивании запускается bash из которого запускается screen, который в свою очередь запускает bash, такой вот слоёный пирог получается.

ага. а что вы хотели?

В этом случае у меня сразу после залогирования сразу же проиходит detach

а что вы ожидали от screen -dR?
Но мысль здравая - exec замещает процесс другим, а не запускает подпроцесс.

Как это не нужно? При запуске screen я теряю то, что было на экране до него, а там может быть куча полезного, например сообщение о пришедшей почте, которое выводится сразу после залогинивания.

можно подумать, внутри screen этого сообщения нет?
ну если нет, покрутите конфиги. Напомнить, в каких файлах?

[t.t]

Неверно. Далеко не всё, что выводится в терминал, по умолчанию пишется в какие-либо логи.

Пример можно?
сообщения ядра пишутся в kernel.log
сообщения об ошибках в errors
syslog тоже не дремлет.
А есть ещё и messages.
Эти логи по-моему, покрывают процентов 90 того, что выводится в терминал.

Далеко не 90%. Практически весь stdout множества как консольных утилит (начиная с coreutils), так и графических программ ни в один лог не попадает. Значительная часть stderr тоже.

Простой пример. Введите в терминале последовательно две строки:

Код: Выделить всё

dpkg -L coreutils | grep bin/ | sed 's|^.*/||' | while read f; do $f --help | head -1; done 2>/dev/null

[core]sudo grep -r КЛЮЧ /var/log[code]
(здесь "КЛЮЧ" -- слово, встречающееся в выводе почти каждой из этих команд)
Вторая не выведет ничего.

[Hephaestus]

Далеко не 90%. Практически весь stdout множества как консольных утилит (начиная с coreutils), так и графических программ ни в один лог не попадает. Значительная часть stderr тоже.

Да я, в общем-то не спорю.
По ходу темы я уже понял своё заблуждение.
Когда-то раньше я случайно увидел в логах вывод одной из программ, чего никак не ожидал увидеть.
С тех пор я полагал, что в логи попадает почти всё. Вот как-то так.

Впрочем, в течение этой темы нашлась-таки утилита, которая действительно логирует всё, что вводится/выводится в терминале. Думаю, на этом можно и закончить.

[sunny1983]

читаю маны. вслух. с выражением. ДОРОГО.

"man 1 bash" или "man 8 bash"? Ладно, сейчас будем разбираться, потому что всё равно ничего не понятно.

bash может стартовать в нескольких режимах: простой коммандный интерпритатор, ограниченный командный интерпритатор, начальный командный интерпритатор, интерактивный коммандный интерпритатор

неа. .bashrc НЕ отработает. При логине работает ~/.bash_login, а вот если запустить bash (из bash'а например), сработает .bashrc. man bash.

bashrc действительно отрабатывается только работе в режиме интерактивного командного интерпретатора,в этом режиме bash запускается с ключём -i

А вот в /etc/passwd:

Код: Выделить всё

adminko:x:1000:1000:,,,:/home/adminko:/bin/bash

В 7 поле bash указан без параметров - значит bash сразу после залогинивания запускается в режиме простого командного интерпретатора. Значит прописывание в /etc/bash.bashrc вообще ничего не принесло бы. Опять глупости говорю, да?

[drBatty]

bash может стартовать в нескольких режимах: простой коммандный интерпритатор, ограниченный командный интерпритатор, начальный командный интерпритатор, интерактивный коммандный интерпритатор

интерпрЕтатор. англ. interpreter.

режимов всего два основных - интерактивный и неинтерактивный. Грубо говоря, неинтерактивный режим включается тогда, когда bash кормить файлом(файлами), а интерактивный во всех остальных случаях. В частности если входной поток и поток ошибок указывают на терминал. Подробнее и точнее:

Код: Выделить всё

INVOCATION
       A login shell is one whose first character of argument zero is a  -,  or  one  started  with  the  --login
       option.

       An  interactive shell is one started without non-option arguments and without the -c option whose standard
       input and error are both connected to terminals (as determined by isatty(3)), or one started with  the  -i
       option.  PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to
       test this state.

       The following paragraphs describe how bash executes its startup files.  If any of the files exist but can‐
       not  be  read,  bash  reports  an error.  Tildes are expanded in file names as described below under Tilde
       Expansion in the EXPANSION section.

       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.  The --noprofile option may be used when the
       shell is started to inhibit this behavior.

       When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.

       When an interactive shell that is not a login shell is started, bash  reads  and  executes  commands  from
       ~/.bashrc,  if  that  file  exists.   This may be inhibited by using the --norc option.  The --rcfile file
       option will force bash to read and execute commands from file instead of ~/.bashrc.

       When bash is started non-interactively, to run a shell script, for example,  it  looks  for  the  variable
       BASH_ENV  in  the  environment,  expands its value if it appears there, and uses the expanded value as the
       name of a file to read and execute.  Bash behaves as if the following command were executed:
              if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
       but the value of the PATH variable is not used to search for the file name.

       If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions  of  sh
       as  closely  as  possible, while conforming to the POSIX standard as well.  When invoked as an interactive
       login shell, or a non-interactive shell with the --login option, it first attempts  to  read  and  execute
       commands  from  /etc/profile and ~/.profile, in that order.  The --noprofile option may be used to inhibit
       this behavior.  When invoked as an interactive shell with the name sh, bash looks for  the  variable  ENV,
       expands its value if it is defined, and uses the expanded value as the name of a file to read and execute.
       Since a shell invoked as sh does not attempt to read and execute commands from any  other  startup  files,
       the  --rcfile  option has no effect.  A non-interactive shell invoked with the name sh does not attempt to
       read any other startup files.  When invoked as sh, bash enters posix mode  after  the  startup  files  are
       read.