SE에는 손상된 터미널을 복구하는 방법을 보여주는 많은 질문이 있습니다 cat /dev/urandom. 이 문제에 대해 잘 모르는 사람들을 위해 설명합니다. 내용은 다음과 같습니다.
cat /dev/urandom또는 이에 상응하는 작업(예: )을 수행합니다cat binary_file.dat.- 쓰레기를 인쇄하십시오.
문제 없습니다...터미널에서 계속 쓰레기를 인쇄하지 않는 한뒤쪽에명령이 완료되었습니다! 다음은 실제로 g++ 출력인 잘못 렌더링된 텍스트의 스크린샷입니다.
사람들이 C++ 오류가 가끔 너무 불명확하다고 생각하는 게 맞는 것 같아요!
일반적인 해결책은 실행하는 것입니다 stty sane && reset. 하지만 이런 일이 발생할 때마다 실행해야 하는 것은 약간 귀찮습니다.
그러므로 제가 집중하고 싶은 것은원래 이유왜 이런 일이 일어나는지, 그리고터미널 손상을 방지하는 방법그러한 명령이 내려지면. 문제의 명령을 실제로 실행/인쇄하기 전에 프로그램/파일 출력 바이너리를 알아야 하고 그러한 데이터를 출력할 때마다 필요할 수 있는 tr솔루션을 찾고 있지 않습니다.xxd
URxvt, PuTTY 및 Linux 프레임 버퍼에서 동일한 동작을 발견했기 때문에 이것이 터미널 관련 문제는 아닌 것 같습니다. 내가 가장 의심하는 점은 무작위 출력에 문자 인코딩을 뒤집는 일부 ANSI 이스케이프 코드가 포함되어 있다는 것입니다(실제로 cat /dev/urandom다시 실행하면 다음과 같을 가능성이 높습니다).침입하다이 이론을 확인하는 것으로 보이는 터미널). 이것이 맞다면 이 이스케이프 코드는 무엇입니까? 비활성화하는 표준 방법이 있습니까?
답변1
아니요:
- "비활성화"하는 표준 방법은 없습니다.
- 파손의 세부 사항은 실제로 터미널마다 다르지만
- 부적절하게 행동하게 만드는 몇 가지 일반적인 특징이 있습니다.
^N일반적으로 사용되는 기능에 대해서는 및 ^O(활성화/비활성화) 로 활성화되는 VT100 스타일 대체 문자 세트를 확인하세요 . 이는 UTF-8 모드를 사용할 때 일부 터미널에서 억제될 수 있지만 동일한 터미널에서는 이스케이프 시퀀스로 화면을 손상시킬 수 있는 충분한 기회가 있습니다(여기서는 GNU 화면, Linux 콘솔, PuTTY를 의미합니다).하다알아내다.
예를 들어, 일부 다른 이스케이프 시퀀스는 호스트 쿼리(이스케이프 시퀀스)에 대한 터미널의 응답에 의존합니다. 호스트가 예상하지 못한 경우 결과는 화면에 정크입니다.
다른 경우(Linux 콘솔에 하드 코딩된 이스케이프 시퀀스가 있는 네트워크 장치 등) 다른 터미널에서는 이것이 잘못 인코딩되었다고 생각하여 정지된 것처럼 보입니다.
따라서... 하나의 터미널에만 집중하고 불쾌해 보이는 모든 것을 제거할 수 있습니다(예: 일부 사람들은 편집기에서 마우스 위치 지정 기능을 제거하는 것을 제안함). 그러면 아마도 명백한 버그가 없는 결과가 나올 것입니다. . 하지만 이것은 단지 터미널일 뿐입니다.
답변2
당신이 통제하고 있고 명령이 당신을 망칠 것이라는 것을 알고 있다면 나는 일반적으로 less 와 같은 출력을 볼 것입니다.
head -n4 /dev/urandom | less
이것은 일반적으로 쓰레기를 잡아서 정상적인 표현으로 인쇄하는 것 같고 나중에는 아무런 문제가 없었던 기억이 납니다.종료하려면 q를 사용하세요., '금단감 줄이기'에 대해 잘 모르실까봐 과감히 지적합니다.
답변3
명령의 출력을 티에 파이프합니다.