If you start an application from a terminal you can see the output to stdout and stderr, but if an application is started from the window manager, where does the output to these files typically go? To /dev/null?
The output of an application started from the window manager goes to the same place as the output from the window manager itself. (Unless the application redirects it, but typical GUI applications don't.)
You can find out where the WM's output goes by looking at what it has open on file descriptor 1 (standard output) and file descriptor 2 (standard error); typically both will go to the same file. Find out the process ID of your window manager (try e.g.
pgrep metacity or
pidof metacity if Metacity is your window manager — if you don't know the process name for your window manager, look at the root of one of the process trees reported by
ps f or
pstree). Supposing the process ID of your window manager is 1234, run
and look for the lines corresponding to file descriptors 1 and 2, or
ls -l /proc/1234/fd
You can automate the filtering of the relevant file descriptors:
lsof -p1234 | awk '$4 ~ /^[^0-9]/' ls -l /proc/1234/fd/
(Note: all the commands above are for Linux.
pgrep is common among other unices, and
lsof can be installed pretty much anywhere;
ps options and
/proc contents are different across different unices.)
In the common situation where you're running commands from a shell running in a terminal emulator (xterm, konsole, gnome-terminal, etc., but not when used across screen or tmux), then you can easily check where the terminal emulator's output is going, as the terminal emulator is the parent process of your shell. This doesn't work if the terminal emulator is running with additional privileges, which happens on some systems to allow the terminal emulator to write to the logged-in user list (utmp).
lsof -p$PPID ls -l /proc/$PPID/fd
Many distributions direct the output of the X session to
The window manager is the child of the X server, so it and its children's output go to the same place as the X server.
If you are the only user and you login graphically, some systems displace the X server instance from the output console, meaning you can switch to that VT and see it. Anecdotally, the arrangement is usually that
alt-ctrl-f1 is the output console for the X instance and
alt-ctrl-f7 is the X display, but you can check as many as you can find. The first 6 usually spawn logins, but there are potentially more that do not and will appear blank or with piped output. There might be output on some of them from init, don't confuse that with output from X. In my experience X and children always bark up a significant amount of warnings and messages (about missing fonts, depreciated calls, etc).
If you don't log in via a GUI, it will be whatever VT you started X from, which is a problem since you won't see that until you quit. I believe with a GUI login, XDM (the graphical login) runs as a privileged process, meaning it can pipe output to
/dev/tty7. You can too (
startx 1>&2> /dev/tty7) if you have the right superuser privileges.
If you take that typically one program starts another by doing series of
man 2 fork and
man 2 execve then in that process by default file descriptors remain open.
So the answer is that typically the output / error goes where parent's process output / error was pointing at fork time (unless the parent program does some redirections of course). I think you can't claim anything more specific unless we know the name of the parent program exactly. Window manager process is rarely involved in launching other programs directly.
For example in my case
- pressing Ctrl+P (handled by
xmonadwindow manager) will start
dmenu_runwill handle my input and start some application (eg.
The output will go to
xkillwas started by
dmenu_runwas started by
xmonadwas started by
Xwas started by
startxwas started by me manually from first virtual console
Just for a reference, if you want to find where output / error goes, or better say what are file descriptors opened for a particular process (with known PID), do
$ lsof -p PID