如果从终端启动应用程序,则可以看到stdout和stderr的输出,但是如果是从窗口管理器启动的应用程序,则这些文件的输出通常在哪里?要/ dev / null?
~/.xsession-errors
如果从终端启动应用程序,则可以看到stdout和stderr的输出,但是如果是从窗口管理器启动的应用程序,则这些文件的输出通常在哪里?要/ dev / null?
~/.xsession-errors
Answers:
从窗口管理器启动的应用程序的输出与窗口管理器本身的输出位于同一位置。(除非应用程序将其重定向,但典型的GUI应用程序不会重定向。)
通过查看文件描述符1(标准输出)和文件描述符2(标准错误)上打开的内容,可以找到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上使用时,则可以轻松检查终端仿真器的输出位置即将结束,因为终端仿真器是Shell的父进程。如果终端仿真器以其他特权运行,这将不起作用,在某些系统上会发生这种情况,以允许终端仿真器写入已登录的用户列表(utmp)。
lsof -p$PPID
ls -l /proc/$PPID/fd
许多发行版将X会话的输出定向到~/.xsession-errors
。
pidof blackbox
或pgrep blackbox
得到PID的窗口管理器,或直接lsof -p$(pidof blackbox)
。Ttys与此无关。
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启动X的任何VT,这是一个问题,因为您必须先退出才能看到它。我相信XDM(图形登录)通过GUI登录可以作为特权进程运行,这意味着它可以将输出通过管道传输到/dev/tty7
。startx 1>&2> /dev/tty7
如果您具有正确的超级用户权限,也可以()。
startx
或xinit
直接~/.xinitrc
更改,则始终可以根据需要进行调整以进行重定向,然后再执行exec
所需的窗口管理器。我自己从未错过过这种输出。如果我对生成什么GUI应用程序感兴趣,可以从终端运行它。但是实际上这可能会有所帮助,因此我将stdout和stderr重定向~/.xinitrc
到~/.xinitrc.out
。
如果您通常认为一个程序通过执行一系列操作来启动另一个程序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与该进程相关联。如果没有或“?” 它可能会迷失在虚无中。(这只是一个主意,我可能是错的)