단일 또는 이중 꺾쇠 괄호를 사용하여 / dev / null로 리디렉션해야합니까?

여기에서 대부분의 답변 ^{[ 1 ] [ 2 ] [ 3 ]} 은 다음과 같이 단일 꺾쇠 괄호를 사용하여 / dev / null로 리디렉션합니다.

command > /dev/null

그러나 / dev / null에 추가해도 작동합니다.

command >> /dev/null

여분의 캐릭터를 제외하고 이것을하지 않는 이유가 있습니까? / dev / null의 기본 구현에 이러한 "가급적"입니까?

편집 : 개방 (2) 맨 페이지는 말한다 lseek의가 추가 모드에서 파일에 대한 각 쓰기 전에 호출됩니다

O_APPEND
파일이 추가 모드로 열립니다. 각 write (2) 전에 파일 오프셋은 lseek (2)와 같이 파일 끝에 위치합니다. 파일 오프셋 및 쓰기 작업의 수정은 단일 원자 단계로 수행됩니다.

사용하면 약간의 성능 저하가 있다고 생각 >>합니다. 그러나 반면에 / dev / null을 자르면 해당 문서에 따라 정의되지 않은 작업처럼 보입니다.

O_TRUNC
파일이 이미 존재하고 일반 파일이고 액세스 모드에서 쓰기를 허용하는 경우 (예 : O_RDWR 또는 O_WRONLY) 길이 0으로 잘립니다. 파일이 FIFO 또는 터미널 장치 파일 인 경우 O_TRUNC 플래그는 무시됩니다. 그렇지 않으면 O_TRUNC의 효과가 지정되지 않습니다.

POSIX 사양에 따르면 >기존 파일을 잘라야 하지만 O_TRUNC는 장치 파일에 대해 구현 정의되어 있으며 / dev / null이 잘린 것에 응답하는 방법에 대한 단어는 없습니다 .

따라서 / dev / null을 실제로 지정하지 않으면 잘립니다. 그리고 lseek 호출은 쓰기 성능에 영향을 미칩니 까?

정의에 따라 /dev/null작성된 내용은 모두 싱크 되므로 추가 모드에서 작성하는지 여부는 중요하지 않으며 모두 삭제됩니다. 데이터를 저장하지 않기 때문에 실제로 추가 할 것이 없습니다.

결국, > /dev/null하나의 >기호 로 작성 하는 것이 더 짧습니다 .

편집 된 추가 사항은 다음과 같습니다.

open (2) 맨 페이지는 lseek가 추가 모드에서 파일에 쓸 때마다 호출된다고 말합니다.

자세히 읽으면 (강조 표시)라고 표시됩니다.

lseek (2)를 사용하는 것처럼 파일 오프셋이 파일 끝에 위치합니다.

즉, 실제로 lseek시스템 호출을 호출 할 필요 는 없으며 그 효과는 엄격하게 동일 lseek(fd, SEEK_END, 0); write(fd, buf, size);하지 O_APPEND않습니다. 별도의 호출을 사용하면 다른 프로세스가 시스템 호출 사이에 파일을 추가하여 추가 된 데이터를 버립니다. 추가 모드에서는 이것이 발생하지 않습니다 ( 실제 추가 모드를 지원하지 않는 NFS를 제외하고 ).

표준 의 텍스트는lseek 그 시점에서 언급되지 않으며 그 쓰기 만 파일의 끝으로 이동합니다.

따라서 / dev / null을 자르면 실제로 지정되지 않습니까?

참조하는 성구로 판단하면 구현 정의 된 것 같습니다. 제정신 구현은 파이프 및 TTY와 동일하게 작동합니다. 즉, 아무것도 수행하지 않습니다. 미친 구현은 다른 일을 할 수 있으며, 잘림은 다른 장치 파일의 경우 합당한 것을 의미 할 수 있습니다.

lseek 호출이 쓰기 성능에 영향을 미칩니 까?

그것을 테스트하십시오. 주어진 시스템에서 확실하게 알 수있는 유일한 방법입니다. 또는 소스를 읽으면 어디에서든 추가 모드가 동작을 변경하는 위치를 볼 수 있습니다.

원하는 효율성이라면 command >&-대신 사용하십시오. 이렇게하면 파일 디스크립터가 경로 재 지정되지 않고 닫히므로 파일을 작성하는 데 시간이 낭비되지 않습니다.