파일 설명자에 쓰려고 할 때 무슨 일이 일어나고 있는지 이해할 수 없습니까? 원본 내용을 덮어쓴 것 같은데요? 이것이 예상되는 동작입니까?
아래 예에서 이것을 복제했습니다.
$ echo "The quick brown fox ..." > example.txt
$ echo "The quick brown fox ..." >> example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ exec 88<>example.txt
$ cat example.txt
The quick brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
ck brown fox ...
The quick brown fox ...
$ echo "jumped" >&88
$ cat example.txt
jumped
jumped
n fox ...
The quick brown fox ...
답변1
설명자 88에서 읽기를 수행하지 않았기 때문에 현재 탐색 위치는 "0"이므로 해당 지점에서 쓰기가 발생합니다.
반대로, 이 전에 파일을 읽으면 추가 작업이 발생합니다.
bash-4.2$ cat <&88
The quick brown fox ...
The quick brown fox ...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox ...
The quick brown fox ...
hello
more
답변2
@Zoonose가 올바르게 지적했듯이 각 파일 설명자는 연결된 파일에서 자체 읽기 및 쓰기 커서 위치를 갖습니다. 예를 들어 리디렉션을 사용하면 <>셸이나 프로그램(예:)을 통해 파일을 열 수 있습니다 cat.
그러나 "파일 설명자"라고 생각하는 숫자는 커널의 실제 파일 설명자에 대한 참조일 뿐이며 단일 프로세스 내에서 또는 프로세스 간에 파일 설명자에 대해 이러한 참조 번호가 여러 개 있는 것은 완전히 정상입니다.
따라서 터미널 창을 열거나 ssh를 통해 로그인하면 쉘 프로세스에서 fd#0, fd#1 및 fd#2로 연결된 터미널에 열려 있는 단일 파일 설명자로 시작합니다. 파이프나 리디렉션을 사용하지 않는 한, 셸에서 시작된 모든 프로세스는 기본적으로 이러한 프로세스를 상속합니다.
리디렉션은 >>파일 설명자를 O_APPEND쓰기용으로 표시합니다.저것filedescriptor는 커서를 무시하고 파일의 끝으로 이동합니다.
리디렉션 >으로 인해 대상 파일이 한 번만 잘립니다.앞으로모든 글쓰기가 완료되었습니다. 그러므로 이후에 어떤 글을 쓰든대개파일 끝 뒤에 빈 공간을 입력하세요.
파일 쓰기아니요자체적으로 잘림이 발생합니다. 필요한 경우 파일 끝을 늘려서 현재 위치에 있는 내용을 간단히 대체합니다.
이로 인해 somecmd >&88somecmd의 표준 출력(fd#1)이 현재 쉘의 fd#88과 파일 설명자를 공유하게 됩니다. 이는 O_APPEND옵션이 있는 경우 해당 옵션을 공유한다는 의미입니다 . 그것에 익숙해다시 자르십시오. 이는 일회성입니다.
이 경우에 보이는 것은 아무 것도 없다는 것입니다.추가의를 사용하면 가 잘리고 >&88(fd#88은 open으로 사용되지 않기 때문에 >>) 기존 데이터를 덮어쓸 수 있습니다.