Мой опыт показывает, что консенсус в комментариях верен - после того, как буфер терминала был превышен, эти данные теряются (или могут быть настолько хороши, как - это может быть в памяти, которая еще не была перезаписана) - и из-за этого вы не может задним числом увеличить размер буфера.
Этот ответ граничит где-то между комментарием, ответом и, возможно, излишним для вашей ситуации. Это скорее предлагаемый подход, который может решить вашу ситуацию - в частности, проблему незнания того, что вам нужен журнал, пока не стало слишком поздно (не причинно-следственные проблемы трудны), но это не прямой ответ на ваш вопрос.
В любом случае, это было слишком долго для комментария. Я не перечисляю в явном виде весь код, необходимый для реализации этого подхода, в основном потому, что есть множество решений по реализации, которые необходимо принять; если вам нужна более подробная информация, я был бы рад предоставить ее.
Script далеко не приятен, чтобы иметь дело с
Прежде всего, утилита script была предложена в качестве «временного промежутка», чтобы предотвратить потерю данных без увеличения размера буфера (что имеет значение для безопасности, когда установлено неограниченное). Если когда-либо была утилита, которая нуждалась в некотором TLC, script таков. С другой стороны, он был разработан командой ядра. Читайте в это, как вы будете.
Я нахожу, что script часто доставляет больше хлопот, чем стоит (постобработка, чтобы сделать его читаемым наполовину человеком, и т.д.), И вместо этого я начал использовать упрощенный метод для записи stdout, stdin и / или stderr. В некотором смысле это воссоздающий скрипт, но с полным контролем вместо того, чтобы зависеть от жестко заданных настроек логирования script .
Этот подход можно относительно легко интегрировать в ваши сеансы оболочки, и в тех редких случаях, когда вы переполняли буфер терминалов, у вас будет временный файл с этим содержимым. Чтобы сохранить «чистоту» ведения журнала, необходимо выполнить несколько действий по ведению домашнего хозяйства. Кроме того, по умолчанию существуют те же проблемы безопасности (журнал всех выходных данных терминала); Однако существует простой способ шифрования журналов.
Есть 3 основных шага:
- Сконфигурируйте перенаправление так, чтобы вы разделяли стандартный вывод (и, при желании, стандартный вывод) на файл и на терминал. Я сохранил этот пример простым и не направляю stdin или stderr в файл - однако, если вы понимаете пример перенаправления stdout, остальное тривиально.
- Сконфигурируйте .bashrc, чтобы эта запись в журнал начиналась при каждом открытии оболочки.
- Когда данная оболочка закрывается, используйте встроенную в bash
TRAP для вызова пользовательского кода, который прервет запись сеанса (вы можете удалить файл, заархивировать его и т.д.)
При таком подходе у вас будет фактически невидимая сеть безопасности, которая позволит видеть всю историю данного сеанса оболочки (основываясь на том, что вы перенаправляете - опять же, чтобы упростить то, что я показываю только в stdout); когда тебе это не нужно, ты даже не должен знать, что это там.
подробности
1. Настроить перенаправление
Следующий фрагмент кода создаст дескриптор файла 3, который указывает на файл журнала. stdout перенаправляется на 3, и, используя tee , мы затем разделяем этот поток обратно на терминал (эквивалент stdout). Вы можете тривиально добавить stderr в тот же файл команды / журнала, передать его в другой файл или оставить его как есть (без меток).
logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
Вы найдете этот файл журнала намного чище, чем созданный скриптом; он не хранит возвраты, переводы строки и другие специальные символы, которые часто нежелательны.
Обратите внимание, что если вы хотите, чтобы logFile был зашифрован, вы можете сделать это довольно легко, добавив дополнительный этап конвейера после команды tee через openssl.
2. Автоматизировать создание журнала
В .bashrc добавьте тот же код, что и выше. Каждый раз, когда создается новая оболочка, создается файл журнала, относящийся к этому сеансу.
export logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
echo "Current session is being logged in $logFile"
3. Автоматическое закрытие журнала при закрытии оболочки
Если вы хотите, чтобы файл журнала был удален по окончании сеанса, вы можете использовать встроенную функцию trap bash, чтобы определить, заканчивается ли сеанс, и вызвать функцию, например, для обращения к файлу журнала (также в .bashrc).
trap closeLog EXIT
closeLog () {
rm -f "$logFile" >/dev/null 2>&1
}
Очистка журнала сеанса может выполняться несколькими различными способами. Этот подход будет вызываться при закрытии оболочки путем захвата сигнала «выход».
На этом этапе вы можете удалить файл журнала, переместить его / переименовать его, или любое количество вещей, чтобы очистить его. Вы также можете очистить файлы журналов с помощью задания cron, а не с помощью TRAP (если этот подход используется, я бы предложил периодическую очистку, если у вас еще нет настроенного для каталога / tmp; как если бы оболочка bash дает сбой, ловушка EXIT не сработает).
Примечание по обращению с подоболочками
Интересная ситуация сложится с подоболочками. Если новая интерактивная оболочка будет открыта поверх существующей, будет создан новый журнал, и все должно работать нормально. При выходе из этой оболочки (возвращении к родителю) регистрация в этом файле возобновится. Если вы хотите решить эту проблему более четко - возможно, даже поддерживая общий журнал для подоболочек (интерактивный или другой), вам нужно будет обнаружить (в .bashrc), что вы находитесь во вложенной подоболочке, и перенаправить в файл журнала родителя, а не в создавая новый. Вам также нужно будет проверить, не находитесь ли вы в подоболочке, чтобы ваш вызов 'trap' не удалял файл журнала родителя при выходе. Вы можете получить уровень вложенной оболочки из переменной окружения bash SHLVL, в которой хранится «глубина» вашего стека оболочки.
Примечание по содержанию вашего журнала «в чистоте»:
Если вы перенаправите стандартный ввод в файл журнала, у вас будет множество нежелательных артефактов, которые генерирует утилита сценария. Эту проблему можно решить, добавив этап фильтрации (например, sed/grep) между перенаправлением и файлом. Просто создайте регулярное выражение, которое удаляет все, что вы не хотите регистрировать. Для полной очистки потребовалась бы достаточно глубокая обработка (возможно, буферизация каждой новой строки перед записью в файл, очистка, а затем запись). В противном случае будет трудно узнать, когда возврат является «мусором» или предназначен.
