네, 충분합니다.

네, 충분합니다.

기본적으로 표준 파일 설명자 <= 2를 엽니다. 프로그램은 open이러한 설명자를 얻기 위해 시스템 호출을 사용하지 않고도 2 이후의 파일 설명자에 쓰거나 읽을 수 있습니다 . 그러면 프로그램은 어떤 파일 설명자를 어떻게 사용하고 있는지 매뉴얼에 게시할 수 있습니다. 이를 활용하기 위해 POSIX 쉘은 파일을 열고 exec내장 설명자가 있는 설명자에 파일을 할당할 수 있습니다. 그러면 쉘은 해당 설명자와 파일을 사용하는 프로그램을 시작합니다.

이를 수행하는 한 가지 이유는 프로그램이 여러 개의 출력 또는 입력 파일을 원하지만 이를 명령줄 인수로 지정하지 않으려는 경우입니다. 파일이 하나만 있는 경우 표준 파일 설명자를 리디렉션할 수 있습니다.

나는 일반적으로 사용 가능한 프로그램의 매뉴얼에서 그러한 내용을 광고하는 것을 본 적이 없습니다. 실제로 이런 일이 일어날까요? 그런 얘기를 들어본 사람 있나요?

예, 저는 POSIX 세계에 머물고 싶습니다. 따라서 bash 전용 내장 기능은 없습니다. 내장 셸 대신 그런 프로그램이 있는지 궁금합니다.

답변1

<(...)프로세스 대체를 위해 or 를 사용하면 >(...)bash는 임의로 높은 파일 설명자에서 다른 프로그램에 대한 파이프를 열고(예전에는 10부터 계산을 시작했지만 이제는 63부터 계산을 시작한다고 생각합니다) /dev/fd/N명령줄에 따라 이름을 전달합니다. 첫 번째 프로그램 중. 이는 POSIX는 아니지만 다른 쉘에서 지원합니다(ksh88 기능).

그러나 그것은 당신이 실행하고 있는 프로그램이 정확히 하는 일이 아니며, 단지 그것을 보고 /dev/fd/N일반 파일처럼 열려고 시도할 뿐입니다.

  • Autoconf 매뉴얼몇 가지 역사를 언급해 보세요:

    일부 구형 시스템에는 일부 파일 설명자가 남아 있습니다. 관례적으로 /dev/ttyUnix 버전 8(1985)~10(1989)에 로그인하면 파일 설명자 3이 열립니다. 파일 설명자 4는 Stardent/Kubota Titan(1990년경)에서 특별한 목적을 가지고 있었지만 지금은 그것이 무엇인지 기억할 수 없습니다. 두 시스템 모두 더 이상 사용되지 않으므로 이제 파일 설명자 3과 4를 다른 파일 설명자처럼 안전하게 처리할 수 있습니다.

  • 또한, 내가 이것을 검색했을 때라는 도구를 찾았습니다.runit파일 설명자 4와 5는 로그 회전과 관련된 특정 목적으로 사용됩니다.

  • svlogd그리고 매뉴얼 페이지를 인용하자면 :

    svlogd가장 최근 로그 파일을 처리하라는 메시지가 표시 되면 (...). svlogd프로세서가 파일 설명자 5에 쓴 모든 출력은 프로세서가 다음 로그 파일 회전에서 실행될 때 파일 설명자 4에서 저장되고 사용할 수 있게 됩니다.

답변2

네, 충분합니다.

Sato Katsura는 Unix 클라이언트-서버 프로그래밍 인터페이스인 UCSPI를 언급했습니다. 이를 따르는 프로그램은 일반적으로 표준 입력, 표준 출력 및 표준 오류를 사용합니다. 그러나 그 외에도 도구 세트는 더 많은 표준 열린 파일 설명자를 정의합니다. 처음 세 가지 외에도 유사한 표준 파일 설명자를 정의하는 다른 도구 세트가 있습니다.

그들 중 일부는 심지어 서로 일치합니다. 표준 파일이 PC-DOS/DR-DOS/MS-DOS 세계에서 3과 4를 처리하는 stdaux것처럼 stdprn일부 Unix 및 UNIX 세계에서는 파일 설명자 3, 4, 5, 6 및 7이 실제로 일관된 표준 사용법을 갖습니다. Linux 터미널 관리, 로그 관리 및 UCSPI 클라이언트 소프트웨어.

UCSPI 클라이언트 도구

6 및 7: 표준에서 서버로, 표준에서 서버로

UCSPI의 경우 사람들은 일반적으로 서버가 표준 입력 및 출력을 사용하여 통신하는 서버측 프로토콜을 주로 기억합니다. 그러나 기억력이 덜한 클라이언트에서는 tcpclient(Bernstein의 UCSPI-TCP), sslclient(Baxter's/Gifford's/Hoffman의 UCSPI-SSL) 및 tcp-socket-connect(nosh 도구 세트)과 같은 도구가 더 많은 표준 파일 설명자를 사용합니다. 둘 다 연결하는 클라이언트 프로그램은 파일 설명자 6이 네트워크에서 읽기 위해 열리고 파일 설명자 7이 네트워크에 쓰기 위해 열릴 것으로 예상하도록 정의됩니다.

Bernstein의 원래 ucspi-tcp 도구 세트에는 다양한 도구가 포함되어 있습니다 tcpclient. 예: Bernstein의 간단한 http@도구는 다음과 같습니다. (Felix von Leitner는 10여년 전에 더 정교한 기사를 발표했습니다.)

#!/bin/sh
echo "GET /${2-} HTTP/1.0
진행자: ${1-0}:${3-80}
" | tcpclient -RHl0 -- "${1-0}" "${3-80}" sh -c '
  주소>&7
  delcr <&6 실행
' | awk '/^$/ { text=1;next} { if (본문) 인쇄 }'

추가 읽기

터미널 관리 도구

3, 4, 5: 표준 ctty, 표준 PTY 마스터-슬레이브

Daniel J. Bernstein의 원래 PTY 도구 세트는 추가 표준 파일 설명자 정의를 도구 세트에 통합했습니다. 파일 설명자 3은 제어 터미널(Bernstein이 쉘의 작업 제어에 대한 첨부 문서에서 제안한 규칙)이고, 파일 설명자 4는 PTY의 마스터이고, 파일 설명자 5는 슬레이브입니다.

PTY 도구 세트는 아마도 매뉴얼에 정의된 특정 열린 파일 설명자 규칙이 있는 도구의 가장 극단적인 예일 것입니다. ptyspawn매뉴얼 페이지에서는 파일 설명자 0, 1, 2, 3, 4, 5 및 9에 대해 설명합니다.

nosh 도구 세트의 터미널 관리 도구는 이러한 도구 중 일부를 공유합니다. pty-get-tty예를 들어, 열려는 의사 터미널의 마스터 측이 파일 설명자 4로 전달되고 두 당사자 모두 그곳에서 이를 수신할 것으로 pty-run예상합니다 .console-terminal-emulator

추가 읽기

LISTEN_FDS규약

3 이상: 표준 청취

시험 합격을 위한 UCSPI의 의미연결됨소켓, 이 프로토콜은 다음을 전달하기 위한 것입니다.듣다소켓. (이름에 딱 맞습니다.) inetd청취 소켓의 원래 프로토콜은 서버 프로세스의 표준 입력이었고 이는 Bercot의 s6 네트워킹 도구 세트가 여전히 수행하는 작업 중 하나였습니다. 그러나 시스템 세계에서는 서버 프로세스가 동시에 여러 소켓을 수신하도록 하는 것이 아이디어입니다. 따라서 파일 설명자 3 이상을 일련의 것으로 정의하는 이 프로토콜이 출현했습니다.질소파일 설명자를 엽니다.질소환경 변수의 값입니다 LISTEN_FDS.

따라서 설명서에 명시적으로 명시되어 있지 않더라도 이 프로토콜을 포함하는 모든 서버 프로그램에는 예상되는 "표준 수신" 파일 설명자 세트가 있습니다.

tcp-socket-listen그러나 청취 소켓 파일 설명자를 취하고 추가하는 와 같은 도구에 대한 매뉴얼 페이지에서는 이러한 파일 설명자를 명시적으로 언급합니다. 그들은 또한 UPSTART_FDS신흥 세계의 덜 알려진 프로토콜을 지적합니다 .

추가 읽기

로깅 도구

4 및 5: 표준 회전 데이터

이미 살펴보았듯이 Bernstein으로 시작하는 규칙은 multilog로그 회전 시 생성되는 도구 및 후속 도구에 대한 규칙입니다. multilog이 모든 것은 스핀 필터 프로그램 실행 사이에 데이터를 전달하는 방법으로 파일 설명자 4와 5를 정의합니다.

추가 읽기

  • 조나단 데보인 폴라드(2015). "기록". 데몬 도구 계열. 자주 주어지는 답변입니다.

사용자 관리 도구

3: 표준 인증서

원래 POP3 서버 로그인을 인증하는 데 사용되었던 Bernstein의 checkpassword인터페이스는 추가 파일 설명자를 열 것으로 예상되는 또 다른 도구 세트를 정의합니다. 다시 말하지만, 생성 프로그램이 암호 검사기가 유효성을 검사하는 사용자 계정 자격 증명을 작성했거나 쓰고 있는 것으로 예상되는 파일 설명자 3입니다. 이제 checkpassword호환 가능한 프로그램의 전체 하위 제품군이 있습니다 .

추가 읽기

관련 정보