스크립트와 데이터를 stdin으로 쉘 및 해당 하위 프로세스로 파이프하려고합니다. 기본적으로 쉘을 시작하여 "exec wc -c;\n<data>"
과 같은 문자열을 stdin을 통해 쉘에 보냅니다.bash/sh/busybox가 stdin을 하위 프로세스로 전달합니다.
하위 프로세스를 시작하고 해당 하위 프로세스로 데이터를 전달하려고합니다. 사용 exec
wc -c
은 내 셸을 바꾸고 stdin을 통해 보낸 바이트 수를 계산합니다.
예 :
echo -ne 'exec wc -c;\nabc' | dash
echo -ne 'exec wc -c;\nabc' | bash
echo -ne 'exec wc -c;\nabc' | bash --posix
echo -ne 'exec wc -c;\nabc' | busybox sh
는하지만 대시 또는 busybox sh
와, bash는 일관되게 작동하는 것 같다. 둘 다 간헐적으로 실패하는 것 같습니다. stdin 위로 <data>
을 보내기 전에 100ms 동안 잠자기하면 작동합니다. 그러나 수면은 신뢰할만한 문제가 아닙니다.
사실 나는 사소한 양의 데이터를 보내고 있으므로 인코딩하거나 메모리에 저장하고 싶지는 않습니다. 어떤 아이디어?
참고 :이 문제를 해결할 수있는 유용한 사례가 많이 있습니다. 그러나 이것이 왜 일관되게 작동하지 않는지 알아 보려고합니다. 그리고/또는 어떤 쉘 마법 나는 플랫폼 :)를 통해 바람직하게, 안정적으로 작동하도록 할 수
업데이트 : 내가 sh
을 실행하고/표준 출력/표준 오류, 내가 좋아하는 것 표준 입력에 노출 원격 시스템을 명확하게 그러한 설정이 무엇이든 할 수 있음을 증명합니다. "exec cat - > /myfile;\n<data>"
을 보내면 /myfile
에 스트리밍하여 <data>
이 포함될 수 있다고 상상할 수 있습니다. 다시 <data>
이 큰 것으로 상상해보십시오.
기본적으로 sh
에 대해 stdin을 사용하여 시스템을 제어 할 수 있음을 증명하고자합니다. sh
대신에 매우 단순한 것이 있으며 정적 바이너리로 여러 플랫폼에서 즉시 사용할 수 있습니다.
나는 이것이 완전히 미쳤을지도 모른다는 것을 인정하고 나는 SSH 같은 프로토콜을 채택해야한다고 인정할 것이다. 그렇지만 그것을 구현해야 할 것이다.
왜'echo -n 'abc'| wc -c' 또는 더 일반적으로'generatedata | process'가 아닌가? 쉘을 시작한 후'exec'를하는 이점은 무엇이라고 보십니까? – John1024
BTW, 당신이 이식성에 관심이 있다면 * 어떤 * 플래그와 함께'echo'보다는'printf'를 사용하는 습관을 갖기를 원할 것입니다; -n은 POSIX에서 명시 적으로 정의되지 않은 행동입니다. 인수 목록에'-e'가 전달되었을 때 출력시'-e'를 출력하는 것 이외의 것은 j가 아닙니다. 정의되지 않은 공간에 있지만 표준과 반대로 행동해야합니다. 특히 APPLICATION USAGE 섹션을 포함하여 http://pubs.opengroup.org/onlinepubs/009604599/utilities/echo.html을 참조하십시오. –