어떤 이유로 SSH에서 sed로 명령 출력을 파이프할 때 라이브 출력이 없습니다.
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee logging
출력 dit에 개행 문자가 없는 것 같지만 sed 명령을 제거하고 실행하면 다음과 같습니다.
wc -l logging
반환할 올바른 숫자인 6을 반환합니다. 내가 여기서 무엇을 놓치고 있는지 아는 사람 있나요?
[편집] 다음 사항을 언급하는 것을 완전히 잊어버렸습니다. 실행 중
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g"
모든 값은 문제없이 반환되지만 일단 믹스에 tee를 추가하면 ^C를 누를 때까지 출력을 얻을 수 없습니다... stdout 리디렉션도 작동하지 않습니다 (ssh someuser@somehost 2>&1 | sed - e "s/[32//g"> 파일). ssh와 tee만 있으면 잘 작동합니다.
답변1
스트림 편집기, sed, 버퍼, "-u" 또는 "--unbuffered"를 통해 비활성화됩니다.
tail -f some/log_file | sed -u 's/foo//g' | grep bar
답변2
명시적인 명령 없이 실행하면 ssh user@somehost원격 시스템에서 대화형 셸을 시작하도록 ssh를 요청하게 됩니다.
bash와 같은 대화형 쉘은 종종단말기명령줄 및 검색 기록을 편집할 때 환경을 개선하기 위해 터미널 명령을 사용하므로 사용할 수 있습니다. (터미널 명령을 사용하면 전체 화면 제어가 가능합니다.)
그러나 ssh는 기본적으로 터미널(또는 터미널)만 할당합니다.의사 터미널) 표준 출력이 터미널에 연결된 경우.
터미널 프로그램(예: gnome-terminal, rxvt, xterm 등)에서 실행 하는 경우 ssh user@somehost표준 출력은 터미널이므로 ssh는 의사 터미널을 생성하고 원격 대화형 셸은 정상적으로 작동합니다.
예를 들어 어떤 것(무엇이든)을 통해 ssh를 파이프하면 ssh user@somehost | cat표준 출력은 파이프(터미널이 아님)가 되므로 ssh는 터미널을 생성하지 않으므로 원격 대화형 셸이 비정상적으로 작동할 수 있습니다.
가능한 해결책 중 하나는 options 를 전달하여 ssh가 의사 터미널을 생성하도록 강제하는 것입니다 -t.ssh -t user@somehost | cat가능한돕다. (또한 -tt의사 터미널을 강제로 할당하려면 이중 옵션이 필요할 수도 있습니다 .)
또 다른 가능성은 특정 명령에 관심이 있기 때문에 주로 ssh를 실행하는 경우 ssh 명령줄에서 특정 명령을 실행할 수 있다는 것입니다 ssh user@somehost mycommand | cat. 예를 들어 특정 명령을 실행하는 경우 관련된 대화형 셸이 없습니다. 이 경우 작동하는 터미널이 있으면 문제가 발생하지 않을 수 있습니다.
답변3
동일한 명령을 사용하고 다음을 추가해 보겠습니다.
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee --output-error=warn logging
이렇게 하면 표준 출력에 쓸 때 오류가 있는지 확인할 수 있습니다. 이것이 도움이 된다면 알려주세요.
예상을 설치하고 시도해 볼 수 있습니다.
unbuffer ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee logging