여기에 대부분의 답변이 있습니다.1] [2] [삼] 다음과 같이 단일 꺾쇠 괄호를 사용하여 /dev/null로 리디렉션합니다.
command > /dev/null
그러나 /dev/null에 추가해도 작동합니다.
command >> /dev/null
추가 캐릭터 외에 이렇게 하지 않을 이유가 있나요? /dev/null의 기본 구현보다 "더 나은" 것이 있습니까?
편집하다:
이것오픈(2)맨페이지설명하다찾다추가 모드에서 파일에 쓸 때마다 호출됩니다.
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 자르기가 실제로 지정되지 않았습니까? 그리고 할찾다호출이 쓰기 성능에 어떤 영향을 미치나요?
답변1
정의에 따르면 /dev/null여기에 쓰여진 모든 내용이 싱크됩니다.이므로 추가 모드로 쓰는지 여부에 관계없이 삭제됩니다. 데이터를 저장하지 않기 때문에 실제로 추가할 내용이 없습니다.
그래서 결국 기호 > /dev/null를 사용하면 더 >짧아 집니다.
편집된 추가 사항은 다음과 같습니다.
open(2) 맨페이지에서는 추가 모드에서 파일에 쓰기 전에 매번 lseek가 호출된다는 것을 보여줍니다.
주의 깊게 읽으면 다음과 같은 내용이 표시됩니다(강조).
파일 오프셋은 파일 끝에 있습니다.마치찾기(2)
lseek즉, 실제로 시스템 호출을 호출할 필요가 없으며 그 효과도 엄격하게 동일하지 않습니다. 호출하지 않는 것은 추가 모드에서 쓰는 것과 lseek(fd, SEEK_END, 0); write(fd, buf, size);같지 않습니다. O_APPEND별도의 호출을 사용하면 다른 프로세스가 파일에 쓸 수 있기 때문입니다. 시스템 호출 시간 전에 추가 데이터를 폐기합니다. 추가 모드에서는 이런 일이 발생하지 않습니다.NFS는 실제 추가 모드를 지원하지 않습니다.).
이것표준의 텍스트이 시점에서는 언급이 없으며 lseek단지 쓰기가 파일 끝에 있어야 한다는 것뿐입니다.
그렇다면 /dev/null 자르기가 실제로 지정되지 않았습니까?
당신이 인용한 구절을 보면 그것이 성취로 정의된 것이 분명합니다. 이는 정상적인 구현이 파이프 및 TTY와 동일한 작업을 수행한다는 것을 의미합니다. 미친 구현은 다른 작업을 수행할 수 있으며 잘림은 다른 장치 파일에 적합한 것을 의미할 수 있습니다.
lseek 호출이 쓰기 성능에 영향을 줍니까?
시험을 봐요. 이것이 특정 시스템에서 확실히 알 수 있는 유일한 방법입니다. 또는 소스 코드를 읽어서 추가 모드가 동작을 변경하는 위치를 확인하세요.
답변2
효율성을 원한다면 command >&-를 사용하세요. 이렇게 하면 파일 설명자를 리디렉션하는 대신 닫으므로 파일 설명자에 쓰는 데 시간이 전혀 낭비되지 않습니다.