/ 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で特定のものを呼び出すためにこれらのシンボルが必要なのはなぜですか？

それは、シェル（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/...ため、それは機能しません。すべてのファイル（を除く）、シェル（ksh、bashのみ）のみ、リダイレクトのターゲットのみに似ています。catopen("/dev/tcp/...")-

これcat -は、特別に処理されるファイルパスの別の例です。を実行する代わりにopen("-")、ファイル記述子0（stdin）から直接読み取ります。cat多くのテキストユーティリティがそれを行いますが、シェルはリダイレクトを行いません。-ファイルのコンテンツを読むには、、cat ./-またはcat < -（またはcat - < -）が必要です。haveを持たないシステムでは/dev/stdin、bashしかしながら、その（仮想）ファイルからのリダイレクトに対して同様のことをします。GNUは、awk同じことを行い/dev/stdin、/dev/stdout、/dev/stderrでも、それらのファイルが異なる振る舞いをLinuxのようなシステムでは、いくつかの驚きを引き起こす可能性があり、このようなファイルを持っているシステム上で。

zshTCP（およびUnixドメインストリーム）ソケットのサポートもありますが、これはztcp（およびzsocket）ビルトインで行われるため、ksh / bashアプローチよりも制限が少なくなります。特に、ksh / bashではできないサーバーとしても機能します。ただし、実際のプログラミング言語でできることよりもはるかに制限されています。

あなたはアイデアを混乱させているか、ファイルを読んでコマンドを実行しているようです。データと命令の違い。

Googleのフロントページは実行可能なプログラムではありません。もしそうなら、それを実行するのは安全ではありません。

リダイレクト文字（<およびを含む>）は、データをコマンドに送信するために使用されます。

私たちは何ができるcat < /dev/tcp/towel.blinkenlights.nl/23しかし、これは動作しません/dev/tcp/www.google.com/80、我々が送信するまで、このポートなどが応答しませんGET / 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