그것은 쉘 (bash에 의해 복사 된 ksh의 기능)과 쉘만의 기능이기 때문입니다.
/dev/tcp/...
실제 파일이 아닌 경우, 쉘은 /dev/tcp/...
파일 로의 재 지정 시도를 차단 한 다음 해당 파일을 여는 socket(...);connect(...)
대신 open("/dev/tcp/..."...)
(해당 파일을 여는 ) TCP를 작성합니다 .
철자가 그렇게되어야합니다. cat < /dev/./tcp/...
또는 ///dev/tcp/...
작동하지 않으며 대신 해당 파일을 열려고 시도합니다 (대부분의 시스템에는 존재하지 않으며 오류가 발생합니다).
리디렉션 방향도 중요하지 않습니다. 당신이 사용 3< /dev/tcp/...
하거나 3> /dev/tcp/...
또는 전혀 차이를 만들지 3<> /dev/tcp/...
않더라도 3>> /dev/tcp/...
, 해당 TCP 소켓을 통해 데이터를 수신 / 전송하기 위해 해당 파일 설명자를 읽고 쓸 수 있습니다.
그렇게 할 때 cat /dev/tcp/...
, cat
동일한 특수 처리를 구현하지 않기 때문에 작동 하지 않습니다. open("/dev/tcp/...")
모든 파일 (제외 -
), 셸 (ksh, bash 만) 및 리디렉션 대상에만 유사합니다 .
이것이 cat -
특별히 처리 된 파일 경로의 또 다른 예입니다. 를 수행하는 대신 open("-")
파일 디스크립터 0 (stdin)에서 직접 읽습니다. cat
많은 텍스트 유틸리티가 그렇게하지만 쉘은 리디렉션을하지 않습니다. -
파일 의 내용을 읽으려면 cat ./-
, 또는 cat < -
(또는 cat - < -
) 가 필요합니다 . 하지 않는이 시스템에서 /dev/stdin
, bash
그러나 그 (가상) 파일에서 리디렉션에 대한 비슷한 일을 할 것입니다. GNU가 awk
에 대해 동일한 작업을 수행 /dev/stdin
, /dev/stdout
, /dev/stderr
심지어 파일이 다르게 동작 곳 리눅스와 같은 시스템에 약간의 놀라움을 일으킬 수 이러한 파일을 가지고 할 시스템.
zsh
또한 TCP (및 Unix 도메인 스트림) 소켓 지원 기능이 있지만 ztcp
(및 zsocket
) 내장으로 수행되므로 ksh / bash 접근 방식보다 덜 제한적입니다. 특히 ksh / bash가 할 수없는 서버 역할을 할 수도 있습니다. 그래도 실제 프로그래밍 언어로 할 수있는 것보다 훨씬 제한적입니다.