端末からアプリケーションを起動すると、stdoutとstderrへの出力が表示されますが、アプリケーションがウィンドウマネージャーから起動された場合、これらのファイルへの出力は通常どこに行きますか?/ dev / nullに?
~/.xsession-errors
端末からアプリケーションを起動すると、stdoutとstderrへの出力が表示されますが、アプリケーションがウィンドウマネージャーから起動された場合、これらのファイルへの出力は通常どこに行きますか?/ dev / nullに?
~/.xsession-errors
回答:
ウィンドウマネージャから起動されたアプリケーションの出力は、ウィンドウマネージャ自体からの出力と同じ場所に送られます。(アプリケーションがリダイレクトしない限り、通常のGUIアプリケーションはリダイレクトしません。)
ファイル記述子1(標準出力)とファイル記述子2(標準エラー)で開かれているWMを見れば、WMの出力先がわかります。通常、両方とも同じファイルに移動します。ウィンドウマネージャのプロセスIDを調べます(例えば試すpgrep metacity
かpidof metacity
のMetacityがあなたのウィンドウマネージャである場合-あなたはウィンドウマネージャのプロセス名がわからない場合、プロセスツリーの一つの根を見てから報告されps f
たりpstree
)。ウィンドウマネージャーのプロセスIDが1234であるとすると、次のコマンドを実行します。
lsof -p1234
そして、ファイル記述子1と2に対応する行を探します。
または
ls -l /proc/1234/fd
関連するファイル記述子のフィルタリングを自動化できます。
lsof -p1234 | awk '$4 ~ /^[12][^0-9]/'
ls -l /proc/1234/fd/[12]
(注:上記のすべてのコマンドはLinux pgrep
用です。他のuniceの間で共通であり、lsof
ほとんどどこにでもインストールできます。ps
オプションと/proc
内容は、異なるunice間で異なります。)
ターミナルエミュレーターで実行されているシェルからコマンドを実行している一般的な状況(xterm、konsole、gnome-terminalなど。ただし、画面またはtmuxで使用する場合は不可)では、ターミナルエミュレーターの出力の場所を簡単に確認できます。ターミナルエミュレータはシェルの親プロセスであるため、端末エミュレーターが追加の特権で実行されている場合、これは機能しません。これは、一部のシステムでは、端末エミュレーターがログインユーザーリスト(utmp)に書き込みできるようにするために発生します。
lsof -p$PPID
ls -l /proc/$PPID/fd
多くのディストリビューションは、Xセッションの出力をに送信し~/.xsession-errors
ます。
pidof blackbox
またはpgrep blackbox
ウィンドウマネージャのPIDを取得するために、または直接lsof -p$(pidof blackbox)
。Ttyはこれとは何の関係もありません。
ls -l /proc/<blackbox-id>/fd
は、stdoutがに移動し/dev/null
、stderrがに移動することを教えてくれ~/.xsession-errors
ます。
ウィンドウマネージャーはXサーバーの子であるため、ウィンドウマネージャーとその子の出力はXサーバーと同じ場所に送られます。
自分が唯一のユーザーであり、グラフィカルにログインする場合、一部のシステムはXサーバーインスタンスを出力コンソールから置き換えます。つまり、そのVTに切り替えてそれを表示できます。事例として、通常の配置はalt-ctrl-f1
Xインスタンスの出力コンソールでalt-ctrl-f7
あり、Xディスプレイですが、確認できる限りいくつでもチェックできます。最初の6つは通常、ログインを生成しますが、実際には生成せず、空白またはパイプ出力で表示される可能性があります。initからの出力の一部があるかもしれませんが、Xからの出力と混同しないでください。私の経験では、Xと子供は常にかなりの量の警告とメッセージを表示します(フォントの欠落、呼び出しの減価など)。
GUI経由でログインしない場合は、Xを起動したVTになります。これは、終了するまで表示されないため問題です。GUIログインでは、XDM(グラフィカルログイン)は特権プロセスとして実行されるため、出力をにパイプすることができます/dev/tty7
。startx 1>&2> /dev/tty7
適切なスーパーユーザー権限があれば、()もできます。
startx
またはxinit
直接の場合、~/.xinitrc
必要なexec
ウィンドウマネージャーで実行する前に、必要に応じて常にリダイレクトを行うことができます。私自身、この種の出力を見逃したことはありません。GUIアプリケーションが生成しているものに興味がある場合は、ターミナルから実行します。しかし、実際にはそれが役立つかもしれないので、私はstdoutとstderrを~/.xinitrc
にリダイレクトしました~/.xinitrc.out
。
あなたが取る場合はその典型的には、1つのプログラムでは、一連の操作を実行して別のを開始man 2 fork
し、man 2 execve
記述子が開いたままに、デフォルトのファイルで、そのプロセスで、その後。
したがって、答えは、通常、出力/エラーは親プロセスの出力/エラーが分岐時間を指していたところに行きます(もちろん、親プログラムがいくつかのリダイレクトを行わない限り)。親プログラムの名前が正確にわからない限り、これ以上具体的なことはできないと思います。ウィンドウマネージャープロセスは、他のプログラムを直接起動することはほとんどありません。
例えば私の場合
xmonad
ウィンドウマネージャーで処理)を押すと起動しますdmenu_run
dmenu_run
私の入力を処理し、いくつかのアプリケーションを起動します(例。xkill
)出力は、に行きます/dev/tty1
ので、
xkill
によって開始されました dmenu_run
dmenu_run
によって開始されました xmonad
xmonad
によって開始されました X
X
によって開始されました startx
startx
最初の仮想コンソールから手動で開始した /dev/tty1
参考までに、出力/エラーがどこに行くのかを見つけたい場合、または特定のプロセス(既知のPIDを持つ)に対して開かれたファイル記述子は何かをよりよく言いたい場合は、
$ lsof -p PID
ps faux
プロセスに関連付けられているtty / ptsを確認するために使用します。なしまたは「?」の場合 それはおそらく空洞で失われるでしょう。(これは単なるアイデアです。間違っている可能性があります)