name of binary vs. name in GUI

Question

In icedove>preferences>attachments, for 'JEPG image' one can select 'Image Viewer' or 'Use other ...'. It turns out that 'Image Viewer' is actually '/usr/bin/eog' on my system. I only know that because after opening eog on the command line, clicking on 'Help>About', I see "Image Viewer" ... "The GNOME image viewer". It gives you no clue as to what the actual binary is, so, when the program is opened 'via' it's 'Image Viewer' name in icedove, how in heck would you figure out what the actual binary is? Is there some table somewhere, or some list of associations or something? The above is just one example--this problem exists in all GUIs all the time. It's a sad example of Linux trying hard to be as stupid and unhelpful as Windows :-(

Answer 1

If you like to see a full path to binary execution file just execute in terminal

which programm_name

The general association list you can find in $HOME/.local/share/applications/mimeapps.list

Answer 2

In the Unix world with the X Window System (X11)¹, there's no concept of “application”. There are several concepts that overlap but don't match exactly:

• packages — the name you select in a package manager to install the application. If you don't install it via a package manager, there may not be a formal package name. A package may include multiple applications.
• executables — the file that is executed to run the application. Executables have a file name, which may or may not be informative (it is when the path to the application is /usr/bin/foo, not when it's /opt/myapp/bin/run or /home/alice/work/dev/a.out).
• processes — the instance of the application in memory. Running an executable creates a process. Exactly what can be considered a process name is complex and somewhat system-dependent, I won't fully discuss it here. In most cases, you can consider the process name to be the executable's file name.

• toplevel windows — a GUI program, by definition of “GUI”, creates at least one of these. A window has several things that care names of some sort, all of which can be retrieved as properties and have sligtly misleading names:

  • WM_NAME is in fact the window's title. It's what window managers display in the title bar and in task lists. It's meant to be human-readable and frequently changes during the lifetime of the window (e.g. when opening a different file, switching to another tab, etc.).
  • WM_ICON_NAME is similar to WM_NAME, but is used when showing an icon representing a window.
  • WM_CLASS is a pair of names, the instance name and the class name. These names are used by configuration mechanisms such as X resources; see "Xterm" or "xterm" in configuration file for a short introduction. These names are typically the same by default except that the class is capitalized and the instance isn't. I think the class name is the best contender for “application name” — but a program might display multiple toplevel windows with different classes.
• An application may have a menu with an item called “About” which displays a window containing a name. What it puts there is purely the choice of the application developer.

Process viewers, not only text-based such as ps, top and htop, but also most GUI ones such as gnome-system-properties and lxtask, only show information about processes, not about toplevel windows.

There's a technical reason for that: there's no robust way to identify which process displays which window. It's possible, but very unusual, to have multiple processes drawing in the same window. More commonly, there might be no process displaying a window, because X11 is network-transparent — an application can send instructions to the display interface (the X server) over the network. There is no foolproof mechanism to track windows created by remote connections either.

If the application is cooperative (and most are), then two window properties allow you to trace the window to a process:

• _NET_WM_PID: the process ID of the process that created the window.
• WM_CLIENT_MACHINE: the host name of the machine where the process runs.

See What process created this X11 window? for more details. You can query the _NEW_WM_PID property with command line tools such as xprop, xdotool, wmctrl, etc. With xprop, you can display all properties. With xdotool and xprop, click on a window to display information about it. wmctrl can list information about all windows.

xprop _NET_WM_PID WM_CLIENT_MACHINE  # and click on a window
xdotool selectwindow getwindowpid    # and click on a window
wmctrl -lp

Given the process ID, you can obtain information about the process, such as the path to its executable. For example, run the following command then click on a window to display information about the application displaying the window.

ps -o args= -p $(xdotool selectwindow getwindowpid)

To see the path to the executable, under Linux:

readlink /proc/$(xdotool selectwindow getwindowpid)/exe

¹ _{There are projects such as Wayland and Mir that strive to replace X11, but given how many applications exist for X11, they are proceeding slowly and are only viable if they maintain enough compatibility.}