これは、(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 そのようなファイルを実際に持っているシステムでも、それらのファイルが異なる動作をする Linux のようなシステムでは驚きを引き起こす可能性があります。
zsh TCP (および 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