リモートビープ音に「>/dev/console」が使用される理由（echoコマンド）

echo出力を標準出力に書き込みます。これはファイル記述子1です。

の場合、実装echo -e '\a'に応じてBEL文字（ASCIIの0x7バイト値）が書き込まれ、その後にLFまたはBELとLFによってLF（別名改行文字）が書き込まれます。echo-e \a-e 

BEL文字のみを書くにはprintf '\a'。

とにかく、これは問題の核心に大きな影響を与えません。printf、echo標準出力に何を書くべきかを書くのと同じです。

リダイレクトなしで対話型シェルのプロンプトでこのコマンドを入力すると、stdoutはシェルから継承されます。シェルがターミナルエミュレータ（orなど）によってxterm起動された場合、screenファイル記述子1はデバイスファイルxtermで開きます/dev/pt<something>（Or on Linuxを参照）。これは擬似端子ペアのスレーブ端になります。lsof -ad1 -p "$$"readlink -f /proc/self/fd/1

ここで理解すべき唯一のことは、これが一種のコミュニケーションチャネルであるということです。ユーザーの対話を支援するために、より多くの鐘と口笛の音があることを除いて、パイプに似ています。

したがって、printfBELがデバイスファイルに書き込まれると、相手に送信されます。このxterm場合、端末エミュレータ自体です。 BEL文字は、端末と端末エミュレータが特定の方法（\a警告用）でユーザーに警告できるようにする制御文字です。これは、ビープ音、チャイムベル、画面の視覚的な点滅、またはその両方です。xterm通常、X11 API呼び出しを使用するXBell()か、視覚的な着信音を使用するように設定されている場合は、そのウィンドウが点滅します。screenそれ自体は単にBELを次に渡します。所有者接続された端末と画面ウィンドウがアクティブな場所、または端末が発行された場所フラッシュ制御シーケンスまたは「Wuff、Wuff!!」（sic）メッセージは、設定方法によって異なります（参照info screen vbell）。

グラフィックセッションの外でLinuxを実行しているPCにログインしている場合、fd 1はすでにデバイスgettyに開いています。/dev/tty<1-...>ここでは、カーネルはターミナルエミュレータを実装し、出力用のモニタと入力用のキーボードを使用します。同じ原則として、printfカーネルはBELが記録されるとPCスピーカーからビープ音を発します。

対話型シェルのプロンプトでこのコマンドを実行すると、sshfd 1も疑似端末デバイス（）になり/dev/pt<something>、今回はリモートシステムでリモートユーザーのログインシェルを起動するSSHサーバーによって起動されます。擬似端末ペアのもう一方の端はSSHサーバーです。 BEL（または他のもの）が受信されると、sshサーバーは暗号化された接続を介してsshクライアントに送信します。その後、それを標準出力に書き込み、最終的に現在の端末ウィンドウに送信します。

存在する

printf '\a' > /dev/console

シェルはを/dev/console実行する前にファイル記述子1（stdout）でファイルを開きますprintf。

少なくとも/dev/consoleLinuxでは、システムメッセージを受信するために使用されるttyデバイスファイルです。/dev/console通常、他のttyデバイスにリダイレクトされます。 PCはデフォルトで/dev/tty0現在有効になっている仮想端末を指しますが、起動時にカーネルパラメータをconsole=/dev/anything使用して変更したり（たとえば、console=/dev/ttyS0最初のシリアルデバイスにする）、後で変更することもできます（出力セクションの場合）。使用TIOCCONS ioctl()（参照xterm -C）。

とにかく、それは通常機械自体に接続されている端末になります。したがって、ユーザにシステムメッセージを送信するために使用されるチャネルを使用しているので、システム管理者に警告するためにＢＥＬが出力される。

ログインしているすべてのユーザーにメッセージを書き込むにはアプリケーションを使用することも、そのユーザーがwallこれらの通知を無効にしていない場合（使用して）、write1人のユーザー（1台の端末デバイス）にのみメッセージを書き込むこともできます。mesg n