web-dev-qa-db-ja.com

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

13
john doe

それはシェル(bshによってコピーされたksh)の機能であり、シェルのみの機能だからです。

_/dev/tcp/..._は実際のファイルではありません。シェルは_/dev/tcp/..._ファイルへのリダイレクトの試行を傍受し、socket(...);connect(...)を実行します(TCP接続を作成)その場合、open("/dev/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が実行できないサーバーとしても機能しますが、実際のプログラミング言語で実行できるサーバーよりもはるかに制限されています。

29

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

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
4
ctrl-alt-delor