/dev/tcpを使用するには<または>が必要な理由

これは、シェル（bashによってコピーされたkshの機能）であり、シェルだけの機能であるためです。

/dev/tcp/...実際のファイルではない場合、この場合、シェルはファイルへ/dev/tcp/...のリダイレクトの試みを傍受しsocket(...);connect(...)（ファイルを開く）代わりに（TCP接続設定）を実行します。open("/dev/tcp/..."...)

このようにスペルを書く必要があることに注意してください。cat < /dev/./tcp/...または///dev/tcp/...、機能せずにファイルを開こうとします（ほとんどのシステムにはファイルが存在せず、エラーメッセージが表示されます）。

リダイレクトの方向も重要ではありません。3< /dev/tcp/...OR3> /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ができない方法でサーバーとして機能することもできます。しかし、実際のプログラミング言語でできるよりもはるかに制限的です。