6장. 입출력 개요
대부분의 프로그램은 무언가의 유용한 작업을 하기 위하여 입력(데이터 읽기) 또는 출력(데이터 쓰 기)을 필요로 하거나,흔히는 입출력 모두를 필요로 한다. GNU C 라이브러리는 아주 많은 입출력 함 수들을 제공 하고 있어서 가장 적합한 함수가 엄격하게 적용될 수 있도록 하고 있다!
이 장에서는 입력과 출력에 관련된 개념과 용어를 소개한다.GNU의 입출력 도구에 관련된 다른 장 은 다음과 같다.
o 7장 [스트림 입출력],63쪽 은 형식화된 입출력을 포함하여 스트림을 처리하는 고수준 함수를 다룬 다. <역자주>스트림==소스로 부터 입력되는 일련의 문자들
o 8장 [저수준 입출력],103쪽은 기본적인 입출력과 파일쓰기를 통제하는 함수를 다룬다.
o 9장 [파일 시스템 인터페이스],123쪽은 디렉토리를 처리하거나 접근 모드나 소유권과 같은 파일속 성에 관한 함수들을 다룬다.
o 10장 [파이프와 FIFO],145쪽은 기본적인 내부처리 커뮤니케이션 도구들에 관한 정보를 담고 있다.
o 11장 [소켓],149쪽은 네트워크를 지원하는 좀더 복잡한 내부 처리 커뮤니케이션 도구들을 다룬다.
o 12장 [저수준 터미널 인터페이스],185쪽은 터미널이나 다른 연결 장치에 대한 입력과 출력을 처리 하는 방식을 변경하는 함수들을 다룬다.
6.1 입출력의 개념
당신이 어떤 파일의 내용을 읽거나 쓸 수 있으려면 먼저 파일에 연결 채널이나 커뮤니케이션 채널 을 설치하여야 한다.이 과정을 파일열기라고 부른다. 당신은 파일을 읽기모드,쓰기모드 또는 읽기쓰 기 모드로 열 수가 있다.
열려진 파일과의 연결은 스트림으로 나타내거나 파일지시자로 나타낸다.당신은 이것을 실제의 읽기 쓰기 처리를 수행할 함수의 인수에 전달하여, 그 함수가 어떤 파일을 처리할 것인지를 알려준다. 어 떤 함수들은 스트림을 받아서 처리하며, 다른 함수들은 파일지시자를 처리하도록 만들어져 있다.
당신이 파일 읽기나 쓰기를 마쳤을 때는, 그 파일을 닫아줌으로써 연결을 끝마칠 수 있다. 당신이 스트림이나 파일지시자를 일단 닫고나면, 더이상 그 파일에 입력이나 출력을 행할 수 없다.
6.1.1 스트림과 파일지시자
당신이 어떤 파일에 입력과 출력을 하고 싶을 때 당신의 프로그램과 파일간의 연결을 나타내기 위 한 두 개의 기본적인 메카니즘을 선택해야 한다: 파일지시자와 스트림이 그것이다.파일지시자는 int 형태의 대상물로 표현되고, 반면에 스트림은 구조체 FILE의 포인터 대상물(FILE * objects)로 표현 된다.
파일지시자들은 입출력 처리에 대한 일차적이고 저수준인 인터페이스를 제공한다.파일지시자나 스 트림 모두 어떤 장치(터미널과 같은)로의 연결을 나타낼 수도 있고 보통의 파일 뿐만아니라 다른 프 로세스와의 커뮤니케이션을 위한 파이프나 소켓과의 연결을 나타낼 수도 있다. 그러나, 만약 당신이 특정한 종류의 장치에 국한된 통제 처리를 하고 싶다면, 반드시 파일지시자를 사용해야만 한다;이러 한 방식에서 스트림을 사용하는 도구는 없다. 블럭화되지 않은(또는 등록된?) 입력(8.10[파일 상태 플래그],116쪽 참조)과 같이 특별한 모드로 입출력을 할 필요가 있을 때도,당신은 반드시 파일지시를 사용하여야 한다.
스트림은 일차적인 파일지시자 도구들 위에 차곡차곡 쌓아 올려진 고수준의 인터페이스를 제공한다. 스트림 인터페이스는 아주 흡사한 모든 종류의 파일을 다루지만 당신이 선택할 수 있는 세가지 양 식의 버퍼(7.17 [스트림 버퍼],95족 참조)에서만 예외가 있다.
스트림 인터페이스를 사용하는 주된 이점은 스트림을 입출력 처리하는(통제처리와 다른 것으로서) 함수들의 세트가 그에 상응하는 파일지시자 사용도구들에 비해서 훨씬 풍부하고 강력하다는 점이다. 파일지시자 인터페이스는 단순히 문자 블럭을 옮겨주는 함수들만을 제공하는 데 반해, 스트림 인터 페이스는 문자단위및 행단위 입출력 뿐만아니라 강력한 형식화된 입출력(printf와 scanf) 함수들까지 제공한다.
스트림은 파일지시자에 의해 완성되므로 당신은 스트림에서 파일지시자만을 뽑아내서 직접 파일지 시자만을 저수준 처리할 수 있다. 당신은 처음에 파일지시자를 써서 (파일을) 연결하였다가, 나중에 스트림을 만들어서 그 파일지시자와 일치시킬 수도 있다.
일반적으로,파일지시자로써만 작동시키고 싶은 어떤 특별한 처리가 아니라면,파일지시자보다는 스트 림을 사용하는 습관을 갖는게 좋다. 만약 당신이 초보 프로그래머이고 사용할 함수들을 잘 모른다면,
당신은 집중적으로 형식화된 입력(7.11 [형식화된입력],85쪽 참조)과 형식화된 출력(7.9 [형식화된 출 력],70쪽 참조)만을 사용하는 게 좋다.
만약 당신이 GNU 이외의 다른 체제에서 프로그램을 운용하려 한다면, 당신은 파일지시자가 스트림 보다 쉽지 않음을 알고 있어야 한다. 당신은 ANSI C를 쓰는 어떤 체제든 스트림을 제공한다고 기 대해도 좋지만, GNU가 아닌 다른 체제에서는 파일지시자가 전혀 제공되지 않으며, 파일지시자를 처 리하는 GNU 함수의 부수적인 부분을 완성할 뿐이다.그러나,GNU 라이브러리의 파일지시자 함수의 대부분은 POSIX.1 표준에 포함된다.
6.1.2 파일 위치
열려진 파일의 속성 중의 하나는 파일에서 다음 문자를 읽어오거나 써야할 장소를 추적하고 있는 파일 위치다.GNU 체제에서는 모든 POSIX.1 체제와 마찬가지로 파일 위치는 그 파일의 시작부분으 로부터의 바이트수로 나타내지는 정수일 뿐이다.
파일위치는 보통 파일이 열렸을 때 파일의 시작위치에 놓여지고,한 문자를 읽거나 쓸 때마다 파일위 치가 증가한다. 달리 말하자면, 파일에의 접근은 정상적으로는 연속적이다.
보통의 파일들은 파일내의 어떤 위치에서든 읽기와 쓰기를 허용한다.어떤 종류의 파일들은 이것을 허용하지 않기도 한다.이것을 허용하는 파일들은 종종 랜덤 파일이라 불린다.당신은 스트림에서 fseek 함수를 사용하여 (7.15 [파일 위치 결정],93쪽 참조) 파일지시자에서 lseek 함수를 사용하여 파 일위치를 변경할 수 있다.당신이 랜덤파일이 아닌 파일에서 파일위치를 변경하려 하면 ESPIPE 에러 를 만날 것이다.
추가모드로 열린 스트림과 파일지시자는 특별히 출력을 위한 것이다: 그러한 파일에 대한 출력은 항상 파일위치에 상관없이 그 파일의 끝부분에 연속적으로 추가한다. 그러나, 파일위치는 여전히 파 일내에서 읽기가 수행되는 곳을 통제하고 있다.
이와 같은 점을 생각해보면,몇개의 프로그램들이 하나의 파일을 동시에 읽을 수 있음을 알 수 있을 것이다.각 프로그램이 자신의 페이스대로 파일을 읽기 위해서는 각기의 파일포인터를 가져야만 하고,
그 파일포인터는 다른 프로그램이 수행하는 어떤 일에 의해서도 영향받지 않아야 한다.
사실은,각각의 파일열기는 다른 파일위치를 만든다. 그러므로, 만약 당신이 같은 프로그램에서 하나 의 파일을 두번 열었다 하더라도, 당신은 독자적인 파일위치를 갖는 두개의 스트림 또는 파일지시자 를 갖게된다.
이와는 대조적으로,당신이 만약 지시자를 열어서 다른 지시자와 중복되게 하였다면,이 두개의 지시자 는 같은 파일위치를 공유하게 된다:하나의 지시자에서 파일위치를 변경시키면 다른 지시자도 영향을 받는다.
6.2 파일 명칭
어떤 파일을 연결하거나 파일 삭제와 같은 다른 처리를 위해서는 그 파일을 참조할 수 있는 어떤 방법이 필요하게 된다.거의 모든 파일은 문자열로 된 명칭을 갖는다_테이프 드라이브나 터미널과 같 은 사실상의 장치조차도 그와 같다.이 문자열들을 파일명칭이라 부른다.당신은 파일명칭을 지정하여 당신이 열거나 처리하고자 하는 파일이 어떤 것인지를 말해줘야 한다.
이 절에서는 파일명칭에 대한 규정들을 기술하고 운영 체제가 그것들을 취급하는 방식을 기술한 다.
6.2.1 디렉토리
파일 명칭의 문장을 이해하려면, 파일체제가 디렉토리 계층으로 조직되는 법을 이해할 필요가
있다.
디렉토리는 다른 파일들을 명칭과 결합시켜주는 정보를 담고 있는 파일이다;이 결합은 링크 또는
디렉토리 엔트리라 불린다.흔히 사람들은 "디렉토리 내의 파일"이라고 말하지만,사실은,디렉토리는
파일에 대한 포인터를 담고 있을 뿐이지 파일 그 자체는 아니다.
디렉토리 엔트리에 담겨진 한 파일의 명칭은 파일명칭 성분으로 불린다.일반적으로, 한 파일의 명 칭은 슬래쉬('/') 문자로 분리된 하나 또는 그 이상의 연속물로 구성된다.단 하나의 성분으로 이루어 진 파일명칭은 그 디렉토리 내의 파일을 지칭한다.여러개의 성분으로 이루어진 파일명칭은 어떤 디 렉토리와 그 디렉토리 내의 파일 등을 지칭한다.
POSIX 표준과 같은 어떤 다른 문서들에서는 소위 파일 명칭 대신에 경로명칭이란 용어를 사용하 며, 이 안내서에서 파일명칭 성분이라고 부르는 것 대신에 파일명칭 또는 경로명칭 성분이란 용어를
사용한다.우리는 이 용어를 사용하지 않는다. 왜냐하면,"경로"는 완전히 다른 것(찾고자하는 디렉토리 들의 목록)이고,우리가 생각하는 바로는 다른 것을 지칭하여 "경로명칭"이라고 해버리면 사용자들을 혼동시키기 때문이다.GNU 문서들에서는 항상 "파일명칭"과 "파일명칭 성분"만을 사용한다.
당신은 9장 [파일체제 인터페이스],123쪽에서 디렉토리 처리에 관한 더 상세한 정보를 얻을 수 있다.
6.2.2 파일 명칭 분석
파일 명칭은 슬래쉬('/') 문자로 분리된 파일 명칭 성분으로 구성된다.GNU C 라이브러리가 지원하 는 체제에서는 여러개의 연속적인 '/' 문자들은단일한 '/' 문자와 동일하다.
파일 명칭이 어느 파일을 참조할 것인가를 결정하는 처리를 파일명칭 분석이라 부른다.이 처리는 파일 명칭을 구성하고 있는 성분을 왼편에서 오른편으로 조사하여,각각의 연속적인 성분을 앞의 성 분에 의해 지칭된 디렉토리에 배치한다. 물론, 디렉토리로 참조되는 각각의 파일들은 실제로 존재해 야 하며, 정규적인 파일 대신에 디렉토리여야 하고, 뿐만아니라 처리에 의한 접근을 허용하는 적절한 권한이 있어야 한다.
만약 어떤 파일명칭이 '/'로 시작되면 그 파일명칭의 최초의 성분은 그 처리의 루트 디렉토리에 위 치 한다.(언제나 체제에서의 모든 처리는 같은 루트디렉토리를 갖는다.) 그와 같은 파일명칭은 절대 적 파일명칭이라 부른다.
그렇지않을 경우,파일명칭에서의 최초 성분이 현재의 작업 디렉토리에 위치한다.(9.1 [작업 디렉토 리],123쪽 참조) 이러한 종류의 파일명칭은 상대적 파일명칭이라 부른다.
파일명칭 성분 '.'("점")과 '..'("점-점")은 특별한 의미를 갖는다.모든 디렉토리는 이 파일명칭 성분 들을 위한 엔트리를 갖는다.파일명칭 성분 '.'는 디렉토리 그 자체를 말하는 반면에,파일명칭 성분 '..'은 그것의 부모 디렉토리(해당 디렉토리와의 연결을 갖는 디렉토리)를 말한다.특별한 경우로서,루 트 디렉토리에 있는 '..'은 루트 디렉토리 그자체를 말하는데,왜냐하면 그것은 부모 디렉토리가 없기
때문이다;이리하여,'/..'은 '/'과 같다.
파일명칭의 예를 보기로 하자.
'/a'
'/a/b'
루트 디렉토리 내의 'a'라 불리는 디렉토리에 있는 'b'라는 파일.
'a'
현재의 작업 디렉토리에 있는 'a'라 불리는 파일.
`/a/./b'
이것은 '/a/b'와 같다.
'./a'
현재의 작업 디렉토리에 있는 'a'라는 파일.
'../a'
현재 작업 디렉토리의 부모 디렉토리 내의 'a'라는 파일.
디렉토리를 지칭하는 파일명칭이 '/'로 선택되어 끝날 수도 있다.당신은 루트 디렉토리를 지칭하기
위하여 '/'라는 파일명칭을 규정할 수는 있지만, 공백문자는 의미있는 파일명칭이 아니다.만약 당신 이 현재의 작업 디렉토리를 지칭하려 한다면,'.'나 '/' 라는 파일명칭을 사용하라.
다른 운영체제들과는 달리,GNU 체제는 파일명칭 문장의 일부로서 파일형태(또는 확장자)나 파일 버 전 을 위한 기존의 지원자를 갖지 않는다.많은 프로그램이나 유틸리티들은 파일명칭에 대한 규정_예 를 들면, C 소스 코드를 담고 있는 파일들은 항상 '.c'를 뒤에 붙인 명칭을 가진다_을 사용하지만,파 일체제 그 자체에는 이와 같은 규정을 강제하는 것은 아무 것도 없다.
6.2.3 파일 명칭 에러
파일명칭 인수들을 받는 함수들은 항상 파일명칭 문장과 관련된 errno 에러조건을 검사한다.이 에 러들은 통상적인 파일명칭 에러가 생길 때마다 이 안내서 전체를 통해서 언급된다.
EACCES
처리가 파일명칭의 디렉토리 성분에 대한 허가권을 찾지 못하였다.
ENAMETOOLONG
파일명칭의 전체 길이가 PATH_MAX보다 더 크거나,개별 파일명칭 성분이 NAME_MAX보다 더 큰 길이를 가질 때 이 에러가 사용된다.
GNU 체제에서는,전체 파일 길이에 대한 주저진 제한은 없다.그러나 어떤 파일 체제에서는 성분의 길이에 대한 제한들을 두고 있을 것이다.
ENOENT
파일명칭 내에서 디렉토리 성분으로서 지칭된 파일이 존재하지 않거나,어떤 성분이 그 대상 파일이 존재하지 않는 부호링크일 때,이 에러가 보고된다.
ENOTDIR
파일명칭 내의 디렉토리 성분으로 지칭된 파일이 존재하지만,그것이 디렉토리가 아니다.
ELOOP
파일명칭을 찾는 동안 너무 많은 부호링크가 분해되었다.체제는 루프를 조사할 일차적 방법으로서의 부호링크가 하나의 파일을 찾는데서 분해될 수 있는 갯수를 임의로 제한하고 있다. 9.4 [부호 링 크],127쪽 참조.
6.2.4 파일명칭의 운용
6.2 [파일명칭],58쪽에서 언급한 파일명칭 문장에 대한 규칙은 GNU 체제와 다른 POSIX 체제에서 정상적으로 사용되는 규칙들이다.그러나 다른 운영체제에서는 다른 규정들을 사용할 것이다.
당신이 파일명칭 운용 문제를 아는데서 그것이 중요할 수 밖에 없는 두 가지 이유가 있다.
o 만약 당신의 프로그램이 파일명칭 문장에 가정문을 넣거나 삽입된 리터럴 파일명칭 문자열을 포 함한다면 그것을 다른 문장 규정을 갖는 다른 운영 체제에서 실행하려할 때 어려움이 많을 것이다.
o 설령 당신이 다른 운영체제로 작동하는 장치에서 당신의 프로그램을 실행하려는 의사가 없다하더 라도 다른 명칭 규정을 사용하는 파일들에 접근하는 일은 여전히 있음직한 일이다. 예를 들어,당신 은 네트워크 상에서 다른 운영체제를 작동시키는 다른 어떤 컴퓨터의 파일에 접근하거나 다른 운영 체제에 의해 포맷된 디스크에서 읽기 쓰기를 할 수 도 있을 것이다.
ANSI C 표준에서는 파일명칭 문장에 관한 언급이 거의 없고 다만 파일명칭이 문자열이란 설명만 있다. 운영체제가 달라짐에 따라 파일명칭의 길이에 대한 제한규정과 파일명칭에 사용될 수 있는 문 자의 종류가 변화할 뿐 아니라,구조화된 디렉토리와 파일 형태, 확장자와 같은 개념에 대한 규정과 문장이 달라진다. 파일 버젼과 같은 개념들은 어떤 운영체제에서는 지원되지만 그렇지 않은 경우도 있다.
POISIX.1 표준에서는 파일명칭에서 허용되는 문자와 관련하여 파일명칭 문장에 대한 추가적인 제 한을 보충 할 수 있도록 하고 있으며,또한,파일명칭과 파일명칭 성분 문자열의 길이에 대한 추가적인 제한도 보충할 수 있도록 하고 있다.그러나, GNU 체제에서는 당신은 이러한 제한에 대해 염려할 필 요가 없다; 널문자를 제외한 어떠한 문자든지 파일명칭 문자열에 허용되며, 파일명칭 문자열 길이에 대한 제한도 없다.