/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で特定のものを呼び出すためにこれらの記号が必要なのはなぜですか?
それはシェル(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が実行できないサーバーとしても機能しますが、実際のプログラミング言語で実行できるサーバーよりもはるかに制限されています。
アイデアを混乱させているか、ファイルを読み取ってコマンドを実行しているようです。データと命令の違い。
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