완료된 터미널 명령의 이전 출력을 모두 보려면 어떻게 해야 합니까?

완료된 터미널 명령의 이전 출력을 모두 보려면 어떻게 해야 합니까?

예상했던 것보다 더 많은 출력을 터미널에 인쇄하는 명령을 gnome 터미널에서 실행했습니다. 전체 출력을 읽고 싶지만 시작 부분에 도달하기 전에 터미널 스크롤이 중지됩니다.

무제한 스크롤을 활성화하거나 출력을 파일로 파이프하는 등의 작업을 위해 터미널 프로필 설정을 변경할 수 있다는 것을 이해합니다. 이러한 일반적인 솔루션은 모두 다음에 적용됩니다.미래그러나 출력.

이미 실행된 명령의 전체 터미널 출력을 보려면 어떻게 해야 합니까?

편집: 좋습니다. 할 수 없습니다. 감사합니다 여러분!

답변1

내 경험에 따르면 의견의 합의는 정확합니다. 일단 터미널의 버퍼가 초과되면 해당 데이터는 손실됩니다(또는 아직 덮어쓰지 않은 메모리에 있을 수도 있음). 버퍼 크기를 소급하여 늘릴 수 없습니다.

이 답변은 의견, 답변 및 귀하의 상황에 대한 과잉 사이의 경계선에 있습니다. 이는 귀하의 상황을 해결할 수 있는 제안된 접근 방식에 가깝습니다. 특히 너무 늦을 때까지 로그가 필요하다는 것을 알지 못하는 문제(인과 관계가 없는 문제는 어렵습니다)이지만 귀하의 질문에 대한 직접적인 대답은 아닙니다.

아무튼 코멘트가 너무 길어졌습니다. 이 접근 방식을 구현하는 데 필요한 모든 코드를 명시적으로 나열하지는 않습니다. 주로 내려야 할 구현 결정이 많기 때문입니다. 더 자세한 정보가 필요하시면 기꺼이 제공해 드리겠습니다.

Script다루기가 즐겁지 않다

우선, 이 script유틸리티는 버퍼 크기를 늘리지 않고(무제한으로 설정하면 보안에 영향을 미침) 데이터 손실을 방지하기 위한 '미봉책'으로 제안되었습니다. TLC가 필요한 유틸리티가 있다면 script바로 그것입니다. 그리고 다시 커널 팀에 의해 개발되었습니다. 원하는 대로 읽어보세요.

나는 script종종 그 가치보다 더 많은 문제를 발견하고(반 인간이 읽을 수 있도록 사후 처리하는 등) 대신 stdout, stdin 및/또는 stderr을 기록하는 단순화된 방법을 사용하기 시작했습니다. 어떤 의미에서는 이는 스크립트를 다시 만드는 것이지만 하드 코딩된 script로깅 설정 에 영향을 받는 대신 모든 권한을 갖습니다 .

이 접근 방식은 셸 세션에 상대적으로 원활하게 통합될 수 있으며 드물게 터미널 버퍼가 오버플로된 경우 해당 내용이 포함된 임시 파일을 갖게 됩니다. 로깅을 '깨끗하게' 유지하기 위해 해결해야 할 몇 가지 관리 단계가 있습니다. 또한 기본적으로 동일한 보안 문제(모든 터미널 출력 로그)가 존재합니다. 그러나 로그를 암호화하는 간단한 방법이 있습니다.

3가지 기본 단계가 있습니다:

  1. stdout(및 원하는 경우 stderr)을 파일과 터미널로 분할하도록 리디렉션을 구성합니다. 나는 이 예제를 단순하게 유지했으며 stdin 또는 stderr를 파일로 지정하지 않습니다. 그러나 stdout 리디렉션 예제를 이해한다면 나머지는 사소한 것입니다.
  2. 셸이 열릴 때마다 이 로깅이 시작되도록 .bashrc를 구성합니다.
  3. 특정 쉘이 닫히면 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. 쉘이 닫힐 때 자동으로 로깅을 닫습니다.

세션이 종료될 때 로그 파일을 삭제하려면 bash 내장 trap함수를 사용하여 세션 종료를 감지하고 로그 파일을 처리하는 함수(예: .bashrc에도 있음)를 호출할 수 있습니다.

trap closeLog EXIT

closeLog () {
  rm -f "$logFile" >/dev/null 2>&1
}

세션 로깅 정리는 다양한 방법으로 처리될 수 있습니다. 이 접근 방식은 'exit' 신호를 트래핑하여 쉘이 닫힐 때 호출됩니다. 이 시점에서 로그 파일을 삭제하거나, 이동하거나, 이름을 바꾸거나, 정리할 수 있는 여러 가지 작업을 수행할 수 있습니다. TRAP 대신 cron 작업을 통해 로그 파일을 정리할 수도 있습니다(이 접근 방식을 사용하는 경우 /tmp 디렉터리에 대해 아직 구성한 작업이 없으면 정기적인 정리 작업을 제안합니다. bash 쉘이 충돌하면 EXIT 트랩이 트리거되지 않습니다.

서브셸 처리에 대한 참고 사항

서브쉘을 사용하면 흥미로운 상황이 전개됩니다. 기존 대화형 셸 위에 새 대화형 셸이 열리면 새 로그가 생성되고 모든 것이 제대로 작동합니다. 해당 쉘이 종료되면(상위 쉘로 돌아가기) 해당 파일에 대한 로깅이 재개됩니다. 이 문제를 보다 명확하게 해결하려면(대화식 또는 기타) 하위 쉘에 대한 공통 로그를 유지 관리하려면 .bashrc에서 중첩된 하위 쉘에 있음을 감지하고 상위 로그 파일로 리디렉션해야 합니다. 새로운 것을 만드는 중입니다. 또한 'trap' 호출이 종료 시 상위 로그 파일을 삭제하지 않도록 서브셸에 있는지 확인해야 합니다. 쉘 스택의 '깊이'를 저장하는 bash 환경 변수 SHLVL에서 중첩된 쉘 레벨을 얻을 수 있습니다.

로그를 '깨끗하게' 유지하는 데 참고하세요.

stdin을 로그 파일로 리디렉션하면 스크립트 유틸리티가 생성하는 것과 동일한 원치 않는 아티팩트가 많이 발생하게 됩니다. 이 문제는 리디렉션과 파일 사이에 필터 단계(예: sed/grep)를 추가하여 해결할 수 있습니다. 기록하고 싶지 않은 항목을 제거하는 정규식을 만들기만 하면 됩니다. 완전히 정리하려면 상당히 심층적인 처리가 필요합니다(아마도 파일에 쓰기 전에 각 새 줄을 버퍼링하고 정리한 다음 쓰기). 그렇지 않으면 백스페이스가 언제 '쓰레기'인지 또는 의도된 것인지 알기 어려울 것입니다.

답변2

전통적인 방법은 PuTTY를 사용하고 수천 줄을 유지하는 것이었습니다. PuTTY를 사용하는 Linux(또는 로컬) 사용자가 많지 않기 때문에 화면도 있습니다.

이제 Windows의 명령줄에 ssh가 있으므로 당황하게 됩니다.

관련 정보