command < file
파일 내용을 명령으로 리디렉션하는 데 사용됩니다.
가상 터미널 1(/dev/tty1)에서 을 실행 less < file
한 다음 다른 가상 터미널에서 실행 lsof -p <pid of the less process>
하고 (잘린) 출력을 확인합니다.
FD name
----------------
0r /root/file
1u /dev/tty1
2u /dev/tty1
3r /dev/tty
나는 이것을 다음과 같이 해석합니다.
- 표준 입력은 /root/file입니다. 프로세스는 /root/file에서만 읽을 수 있습니다.
- 표준 출력은 /dev/tty1입니다. 프로세스는 /dev/tty1을 읽고 쓸 수 있습니다. (프로세스에 필요한 이유는 모르겠지만읽다자체 출력에서...)
- 표준 오류는 /dev/tty1입니다. 프로세스는 /dev/tty1을 읽고 쓸 수 있습니다(다시 말하지만 프로세스에 권한이 필요한 이유는 무엇입니까?)읽다오류 로그에서 출력됩니까? )
- 마지막 줄은 비표준 스트림입니다. 그것이 무엇인지는 모르지만 프로세스는 그것으로부터만 읽을 수 있습니다.
질문:stdin
/root/file 임에도 불구하고 여전히 less
프로세스와 상호 작용할 수 있습니다(예: "/"를 입력하여 검색 모드로 들어가 단어를 검색합니다). 이는 프로세스가 여전히 현재 가상 터미널(/dev/tty1)로부터 입력을 받아들인다는 것을 의미합니다. stdin
/dev/tty1이 아니기 때문에 less
키보드 입력을 통해 프로세스와 상호 작용할 수 없어야 한다고 가정합니까 ?
답변1
표준 입력은 /root/file입니다. 프로세스는 /root/file에서만 읽을 수 있습니다.
표준 출력은 /dev/tty1입니다. 프로세스는 /dev/tty1에 읽고 쓸 수 있습니다. (프로세스가 자체 출력을 읽어야 하는 이유는 모르겠지만...)
표준 오류는 /dev/tty1입니다. 프로세스는 /dev/tty1을 읽고 쓸 수 있습니다(다시 말하지만, 프로세스가 출력하는 오류 로그를 읽으려면 왜 권한이 필요합니까?)
"stdout"과 "stderr"는 모두 동일한 파일 객체를 가리키고, 동일한 "stdin"은 에서 리디렉션되기 전에 가리킵니다 /root/file
. 즉, /dev/tty1
둘 다 다음을 통해 얻습니다.반복(2)동일한 파일 설명자와 모든 속성(모드: O_RDWR
, 파일 포인터 등)을 공유합니다. 파일 설명자를 여러 포인터가 동일한 구조를 가리킬 수 있는 (참조 계산된) 포인터 집합에 대한 인덱스로 생각해야 합니다. 쉘이 fcntl(fd, F_SETFL, O_WRONLY)
stdin을 리디렉션할 때 "stdout" 및 "stderr"의 액세스 모드를 변경하지 않습니다. file
이는 의미가 없습니다.
마지막 줄은 비표준 스트림입니다. 그것이 무엇인지는 모르지만 프로세스는 그것으로부터만 읽을 수 있습니다.
이는 less
사용자 상호 작용에 사용되는 것입니다.
문제: 표준 입력이 /root/file임에도 불구하고 less 프로세스와 계속 상호 작용할 수 있습니다(예: "/"를 입력하여 검색 모드로 들어가 단어를 검색합니다). 이는 프로세스가 여전히 현재 가상 터미널(/dev/tty1)로부터 입력을 받아들인다는 것을 의미합니다. stdin이 /dev/tty1이 아니기 때문에 키보드로 입력하여 less 프로세스와 상호 작용할 수 없어야 한다고 가정합니까?
/dev/tty
귀하의 경우 항상 제어 터미널을 열고 동일한 장치(가상 장치 - 의사 터미널)를 참조하는 마법 경로 /dev/tty
입니다 /dev/tty1
.
답변2
특별한 케이스를 전시하고 있습니다. fd 0의 입력 스트림에서 작업하는 동안 less
사용자와 상호 작용하려면 입력 채널이 필요합니다. 따라서 키보드에서 읽기 위해 다른 파일(여기서는 fd 3)을 엽니다. 이것은 확실히 표준 입력이 아닙니다. 내레이터(기억...): DEC의 OpenVMS에서는 기본적으로 SYS$INPUT과 SYS$COMMAND를 구분하는데, 이는 제시된 상황을 어느 정도 반영합니다.