/dev/tcp를 사용하려면 < 또는 >가 필요한 이유

/dev/tcp를 사용하려면 < 또는 >가 필요한 이유

전화를 걸 때 /dev/tcp/www.google.com/80다음을 입력하세요.

/dev/tcp/www.google.com/80

배쉬는 말했다 no such file or directory. 온라인에서 다른 사람의 코드를 볼 때 다음 구문을 사용합니다.

 3<>/dev/tcp/www.google.com/80

나는 이것이 또한 작동한다는 것을 알았습니다.

</dev/tcp/www.google.com/80

Bash에서 무언가를 호출하는 데 이러한 기호가 필요한 이유는 무엇입니까?

답변1

이는 쉘(bash에 의해 복사된 ksh의 기능)이자 쉘만의 기능이기 때문입니다.

/dev/tcp/...실제 파일이 아닌 경우, 이 경우 쉘은 /dev/tcp/...파일로의 리디렉션 시도를 가로채서 socket(...);connect(...)(파일 열기) 대신 (TCP 연결 설정)을 수행합니다.open("/dev/tcp/..."...)

이런 식으로 철자를 써야 한다는 점에 유의하세요. cat < /dev/./tcp/...또는 ///dev/tcp/...작동하지 않고 파일을 열려고 시도합니다(대부분의 시스템에는 파일이 존재하지 않으며 오류 메시지가 표시됩니다).

리디렉션 방향도 중요하지 않습니다. 3< /dev/tcp/...OR 3> /dev/tcp/...또는 3<> /dev/tcp/...OR을 사용하든 아무런 차이가 없습니다 3>> /dev/tcp/.... 해당 파일 설명자에서 읽고 쓸 수 있어 해당 TCP 소켓을 통해 데이터를 받거나 보낼 수 있습니다.

동일한 특수 처리가 구현되지 않았기 때문에 이 작업을 수행할 때 cat /dev/tcp/...작동하지 않습니다. 모든 파일에 대해 유사한 작업을 수행합니다(.only 쉘(ksh, bash만 해당)은 제외하고 리디렉션 대상에만 해당).catopen("/dev/tcp/...")-

이는 cat -파일 경로를 구체적으로 처리하는 또 다른 예입니다. 이번에는 cat셸이 아니라 처리됩니다.

open("-")를 실행 하고 결과 파일 설명자에서 입력을 읽는 대신 cat파일 설명자 0(stdin)에서 직접 읽습니다. cat많은 텍스트 유틸리티가 이를 수행하지만 쉘은 리디렉션하지 않습니다. 파일의 내용을 읽으려면 , 또는 (또는 ) -이 필요합니다 . 그러나 가 없는 시스템에서는 이 (더미) 파일로부터의 리디렉션에 대해 유사한 작업이 수행됩니다. 그러한 파일이 있는 시스템에서도 GNU는 에서 동일한 작업을 수행합니다 . 이는 이러한 파일이 다르게 동작하기 때문에 Linux와 같은 시스템에서 약간의 놀라움을 초래할 수 있습니다.cat ./-cat < -cat - < -/dev/stdinbashawk/dev/stdin/dev/stdout/dev/stderr

zshTCP(및 Unix 도메인 스트림) 소켓 지원도 있지만 이는 ztcp(및 ) 내장 기능을 통해 zsocket수행 되므로 ksh/bash 접근 방식보다 덜 제한적입니다. 특히 ksh/bash가 할 수 없는 방식으로 서버 역할을 할 수도 있습니다. 하지만 실제 프로그래밍 언어로 할 수 있는 것보다 훨씬 제한적입니다.

답변2

아이디어를 혼동하거나 파일을 읽고 명령을 실행하는 것 같습니다. 데이터와 명령어의 차이.

Google 홈페이지는 실행 가능한 프로그램이 아닙니다. 그렇다면 실행하는 것이 안전하지 않습니다.

리디렉션 문자( <및 포함 >)는 데이터를 명령으로 전달하는 데 사용됩니다.

이렇게 할 수는 있지만 보낼 때까지 포트가 응답하지 않기 때문에 cat < /dev/tcp/towel.blinkenlights.nl/23작동하지 않습니다./dev/tcp/www.google.com/80GET / HTTP/1.0\r\n\r\n

그러니 시도해 보세요

{
  printf >&3 'GET / HTTP/1.0\r\n\r\n'
  cat <&3
} 3<>/dev/tcp/www.google.com/80

관련 정보