배경
우리 대부분은 필터와 파이프가 Unix 시스템의 기초라는 데 동의합니다.
파이프와 필터는 매우 강력한 도구입니다. 거의 모든 Unix 유틸리티는 기본적으로 표준 입력 및 출력 스트림을 사용하므로 파이프에서 사용할 수 있습니다.
Unix에서 유틸리티를 실행하기 위한 규칙입니다.표준 입력그리고표준 출력다른 입력/출력 파일이 지정되지 않은 경우.
grep
, as
, sed
, tr
, perl
, sort
, uniq
, bash
및 기타 많은 유틸리티는 이 규칙 cmp
을 cat
따르는 유틸리티입니다.
그러나 많은 프로그래밍 유틸리티는 이 규칙을 포기했습니다.
입력 읽기
가장 확실한 예는 cc
(C 컴파일러)입니다.
매개변수 없이 호출 하면 cc
다음 메시지를 받게 됩니다.
ryvnf:~$ cc
cc: fatal error: no input files
compilation terminated.
이것이 유일한 예는 아닙니다:
ryvnf:~$ yacc
/usr/bin/bison: -y: missing operand
Try '/usr/bin/bison --help' for more information.
as
읽기 와 같은 하위 수준 유틸리티표준 입력기본적으로. 이유를 모르겠습니다.
출력 쓰기
이는 출력에도 적용됩니다.
cc
기본적으로 실행 코드를 a.out
. 파서 생성기는 yacc
생성된 파서를 y.tab.c
.
나에게는 기본적으로 표준 입력/출력 스트림을 사용하는 것이 다양한 유틸리티를 쉽게 연결할 수 있다는 점에서 유리합니다. 이 파이프라인과 마찬가지로 중간 파일을 생성하지 않고 yacc 파서를 실행 가능한 코드로 한 번에 컴파일합니다 y.tab.c
. 예를 들면 다음과 같습니다.
yacc parser.y | cc -o parser
내 질문
프로그래밍 유틸리티가 다른 많은 Unix 유틸리티처럼 기본적으로 표준 스트림을 사용하지 않는 이유는 무엇입니까?
사용하지 않는 동기는 무엇입니까?표준 입력 스트림기본적으로 이러한 유틸리티는 무엇입니까?
노트나는 당신이 cc
읽을 수 있다는 것을 알고 있습니다표준 입력사용하여 cc -x c -
. 이것은 작동하지만 왜 기본적으로 이 작업을 수행하지 않는지에 대한 질문이 남아 있습니다.
답변1
파이프는 들어오는 입력을 처리할 수 없기 때문에 소스 코드에서 작동하지 않습니다. 처리가 시작되기 전에 전체 파일을 로드해야 합니다. 컴파일을 위해 여러 파일(예: .h 파일)이 필요한 경우 상황은 더욱 악화됩니다. 표준 입력에서 읽는 경우 파이프로 연결하는 파일 사이에 파일 나누기를 지정하는 데 필요한 모든 파일을 스트리밍할 수 있는 방법이 필요합니다. 문제는 거기서부터 커지기 시작했습니다.
파이프라인의 기본 아이디어는 일련의 간단한 작업이 될 것이라는 것입니다. 컴파일된 코드는아니요이는 간단한 작업이므로 파이프라인의 일부로 설계되지 않았습니다. 파이프라인 이론에서는 또한 개별 구성 요소의 이식성을 높이기 위해 파이프라인의 프로세스 간 모든 통신이 일반 텍스트로 이루어져야 한다고 명시합니다. 정의에 따르면 코드 컴파일과 관련된 출력 cc
은 모델에 적합하지 않은 이진 데이터입니다.yacc
ld