원본 논문

초기 구상

  • Pipeline 은 coroutine 의 특별한 형태일 뿐, UNIX 에서 처음으로 도입한 것은 아니었다.
    • Dartmouth Time-sharing System 에서도 “Communication Files” 이란 이름으로 지금의 UNIX pipe 와 거의 유사한 기능을 제공해 주긴 했다.
    • 다만 이것을 제대로 제공해 주지는 못했고, 따라서 UNIX 에서 | 의 문법을 이용한 간편한 사용법으로 널리 알려지게 된듯
  • Pipe 는 매클로이 아저씨 의 아이디어었는데, 그는 명령어가 마치 이항연산자처럼 명령어의 input 이 왼쪽에 output 이 오른쪽에 들어가야 한다고 제안했다고 한다.
  • 즉, 어떤 input 을 정렬 (sort) 한다음, 페이지를 매기고 (paginate - pr), 프린트를 하는 것 (offline-print - opr) 은 다음과 같이 쓸 수 있을 것이다.
input sort pr opr
  • 위는 지금의 UNIX 표현으로 하자면 다음과 같다:
sort input | pr | opr
  • 이 아이디어는 좋았지만 바로 구현에 들어가지는 못했다고 한다:
    • command input output 의 형태 (마치 cp x y 처럼) 에 너무 익숙해져 있었고
    • 이게 command arg 인지 input 혹은 output 인지 구분하는 게 힘들었기 때문
  • 하지만 시간이 좀 흐른 후, 매클로이 아저씨가 이것을 구현하여 UNIX 에 포함시키게 되었다.
  • 처음의 pipeline 은 지금의 | 가 아닌 I/O redirect 와 동일한 > 를 사용했다고 한다.
  • 즉, 위의 예시는 다음처럼 표현되게 된다:
sort input >pr>opr>
  • 따라서 위와 같은 구현에서는, > 가 두가지의 역할을 하게 된다:
    1. 명령어의 stdout 을 > 뒤에 나오는 파일로 redirect 하거나,
    2. 명령어의 stdout 을 > 뒤에 나오는 command 로 pipe 하거나.
  • 위 구문에서 맨 마지막에 > 가 붙는지 의아할 수 있는데, 이것은 opr 이 명령어임을 나타낸다.
    • 즉, opr 뒤에 > 를 붙이지 않았다면, pr 의 stdout 이 ”opr” 란 이름의 파일에 저장될 것이기 때문.

그리고 개선된 것들..

(1) Quote 활용

  • 이러한 용법이 나온 이후에, 여러가지 개선이 이루어 졌는데, 이루어진 첫번째 개선은 whitespace 에 관한 것이었다.
    • > 뒤에서는 whitespace 를 기준으로 command string 으로 잘라 처리하게 되는데, command arg 또한 whitespace 를 이용해 구분짓기 때문에, 혼동이 오는 것.
  • 가령 위의 예시에서 pr 명령어에 -2 옵션을 주고자 아래와 같이 사용하면:
sort input >pr -2>opr>
  • -2 를 명령어로 인식해 이러한 명령어는 없다고 징징댈 것이다.
  • 이를 개선하기 위해, 이런 경우에는 큰따옴표를 이용해 하나의 명령어로 인식하도록 했다.
    • 즉, 아래와 같이 하면 정상적으로 작동하게 된다.
sort input >"pr -2">opr>

(2) > 뿐 아니라 < 도 지원하기

  • 조금 더 문법을 확장하고자, 왼쪽에서 오른쪽으로 진행해 가는 > 에 추가적으로 반대방향인 < 도 추가되었다.
  • 즉, 위에서의 예시는 다음과 같이 표현할 수도 있었다:
 opr <"pr -2"<"sort input"<
  • "sort input" 뒤에 < 이 붙는 것도 해당 문자열을 파일이 아닌 명령어로 받아들이게 하기 위함이다.
  • >< 를 섞어 사용하면 아래와 같이 사용하는 것도 가능하다:
pr <"sort input"< >opr>
  • 이것은 차근차근 읽어보면 다음과 같다:
    • sort input 의 결과를 ("sort input"<)
    • pr 로 보내고, (pr <"sort input"<)
    • 또 그 결과를 opr 로 보낸 뒤 그 결과는 그냥 stdout 으로 보내는 것 (pr <"sort input"< >opr>)

(3) | 이용하기

  • 위와 같은 >, < 식의 표현은 얼마 간은 지속됐지만 결국에는 현재의 | 방식으로 굳어졌다고 한다.
  • 물론 | 를 사용하는 방식이 문제가 없는 것은 아니다.
    • 가령 여러개의 stream 에서 input 을 받으려고 할 때는, stdout-stdin 을 다이렉트로 연결짓는 | 방식으로는 불가능하기 때문.

Multics 의 redirection 과의 차이점은?

  • Multics 에서도 IO stream 을 process 로 전달하는 redirection 이 가능했기에, UNIX pipe 가 이것의 개선버전이라고 생각할 수 있지만,
  • 저자는 그렇게 생각하지 않는다고 한다:
    • Multics 에서의 IO stream 은 program 이 IO stream 을 지원하기 위한 방식으로만 코드가 작성되어야 하지만
    • UNIX pipe 는 stdin 과 stdout 을 이용하기에 코드에 큰 변화를 주지 않아도 된다는 의미인듯