일단 기본적으로는 이론상으로도 그렇고 실제로도 앞의 명령어가 완전히 종료되고 상태 코드를 받아야만 뒤의 명령어가 실행될 수 있어. 데이터가 버퍼를 꽉 채워도 앞의 명령어 상태 코드가 0이 아닐수도 있기 때문이야. 그리고 파이프는 전용 버퍼를 따로 만들어준다거나 하진 않는데 그 이유가 스트림 자체에 기본적으로 내부 버퍼가 존재하고 앞 명령어의 출력 스트림이 뒤 명령어의 입력 스트림으로 들어가는 방식이라 파이프 버퍼는 그저 추상적인 개념으로만 생각해. 어차피 유닉스는 모든게 파일이야.
grep 보니까 프로그램마다 다른거 같네
그거야 파이프를 어떻게 사용하느냐 코딩을 해야하니까 - dc App
grep은 line-buffer 여부 제어가 가능한데 cat은 안되나 봐 임의의 명령어를 line-buffer할지 안할지 제어해주는 명령어는 없나 stdbuf 써봤는데 안되더라 어떻게 쓰는지 잘 몰라서 그런가
파이프는 보통 다 읽고 나서 넘겨줄 걸
unix pipe는 앞 뒤 명령어가 어떻게 동작하는지 관심 없음. 앞 명령어가 쓰면 파이프 내부 버퍼에 넣어주고 뒷 명령어는 그 내부 버퍼에서 읽어갈 수 있게 될 뿐이야.
버퍼링 제어 참고
https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe
다 읽고 넘겨주면 pv가 어떻게 존재하냐?
일단 기본적으로는 이론상으로도 그렇고 실제로도 앞의 명령어가 완전히 종료되고 상태 코드를 받아야만 뒤의 명령어가 실행될 수 있어. 데이터가 버퍼를 꽉 채워도 앞의 명령어 상태 코드가 0이 아닐수도 있기 때문이야. 그리고 파이프는 전용 버퍼를 따로 만들어준다거나 하진 않는데 그 이유가 스트림 자체에 기본적으로 내부 버퍼가 존재하고 앞 명령어의 출력 스트림이 뒤 명령어의 입력 스트림으로 들어가는 방식이라 파이프 버퍼는 그저 추상적인 개념으로만 생각해. 어차피 유닉스는 모든게 파일이야.