Red Hat Enterprise Linux 6.4 시스템에서 GNU Screen 4.00.03을 사용할 때 약간 이상한 동작을 발견했습니다.
Screen 없이 연결하고 로그를 보면 0x0D 0x0A예상한 대로 각 줄이 CRLF() 로 끝나는 것을 볼 수 있습니다.
Screen을 연결하고 실행하면 두 개 이상의 문자가 포함된 줄이 예상대로 CRLF로 종료됩니다. 인쇄 문자가 없는 줄(예: naked 실행 echo)은 LF()로만 끝나며 0x0A, 가장 이상하게도 단일 인쇄 문자(예: echo x)가 있는 줄은 BSLF()로 종료됩니다 0x08 0x0A.
PuTTY를 사용하여 이것을 보았는데, 위의 로그는 PuTTY 로그에서 가져온 것입니다. 나는 Pexpect를 사용하는 자동화된 Python 프레임워크에서도 이것을 본 적이 있으므로 PuTTY를 비난하지는 않습니다.
어떻게 되어가나요? 어떻게 막을 수 있나요?
답변1
이는 최적화에 의해 수행됩니다 screen.
echo<Cr>을 입력 하면 screen로컬 에코와 창의 의사 터미널 장치 설정 덕분에 icrnl시퀀스가 마스터(화면)로 전송됩니다.onlcrscreen\r\n
screen\r커서를 줄의 시작 부분으로 이동하고 \n커서를 아래로 이동 하도록 설계된 터미널 에뮬레이터를 구현합니다 . 이를 위해 커서를 줄의 시작 부분으로 이동하기 위해 X API 호출을 수행하는 xterm과 같은 터미널 에뮬레이터는 screen연결된 호스트 터미널에 이스케이프 코드를 보내 커서를 시작 부분으로 이동하도록 지시해야 합니다. 라인의. 화면 창의 왼쪽입니다.
창을 수직으로 분할하면 커서 위치 지정 이스케이프 시퀀스가 화면 창 왼쪽의 임의 위치로 전송된다는 의미입니다. 그렇지 않은 경우 또는 호스트 터미널의 왼쪽에 있는 경우 커서가 줄의 시작 부분으로 이동하고 호스트 터미널에서 한 줄 아래로 이동하도록 다음 문자를 전달하면 됩니다(모든 터미널이 그러한 screen경우 에도 마찬가지 이므로 ). 같은).\r\n\r\n
이제 문자 echo를 실행하고 출력해 보세요 \n. onlcr다시 screentty 창 에서 다시 수신하기 때문입니다 screen. 줄의 시작 부분으로 이동하라고 지시하지만 커서는 이미 줄의 시작 부분에 있으므로 아무 작업도 수행할 필요가 없습니다. 이것이 바로 호스트 터미널이 두 번째 문자를 받지 못하는 이유입니다. 그런 다음 호스트 터미널로 수신하고 전송하면서 커서를 아래로 이동합니다.\r\n\r\r\nscreen\n
화면에서 실행하여 이를 확인할 수 있습니다.
printf '\r\r\r\r'
screen당신은 단지 보내는 것을 알 수 있습니다하나 \r호스트 터미널에 문자를 보냅니다.