name of binary vs. name in GUI
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 :-(
debian xfce gui desktop mime-types
add a comment |
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 :-(
debian xfce gui desktop mime-types
In terminal executewhich eog
and receive/usr/bin/eog
– Costas
Feb 10 '15 at 22:05
1
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36
add a comment |
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 :-(
debian xfce gui desktop mime-types
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 :-(
debian xfce gui desktop mime-types
debian xfce gui desktop mime-types
edited Feb 15 at 5:25
Rui F Ribeiro
40.7k1479137
40.7k1479137
asked Feb 10 '15 at 21:58
Ray AndrewsRay Andrews
7653826
7653826
In terminal executewhich eog
and receive/usr/bin/eog
– Costas
Feb 10 '15 at 22:05
1
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36
add a comment |
In terminal executewhich eog
and receive/usr/bin/eog
– Costas
Feb 10 '15 at 22:05
1
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36
In terminal execute
which eog
and receive /usr/bin/eog
– Costas
Feb 10 '15 at 22:05
In terminal execute
which eog
and receive /usr/bin/eog
– Costas
Feb 10 '15 at 22:05
1
1
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36
add a comment |
2 Answers
2
active
oldest
votes
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 toWM_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.
add a comment |
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
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f184113%2fname-of-binary-vs-name-in-gui%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 toWM_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.
add a comment |
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 toWM_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.
add a comment |
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 toWM_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.
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 toWM_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.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Jul 23 '15 at 17:43
GillesGilles
540k12810931606
540k12810931606
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Feb 10 '15 at 22:19
CostasCostas
12.7k1129
12.7k1129
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f184113%2fname-of-binary-vs-name-in-gui%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
In terminal execute
which eog
and receive/usr/bin/eog
– Costas
Feb 10 '15 at 22:05
1
grep -H Name /usr/share/applications/*.desktop
– muru
Feb 10 '15 at 22:15
Thanks muru :-) Make that an answer so I can upvote it.
– Ray Andrews
Feb 10 '15 at 22:40
Costas: Once I know the name of the binary it's not a problem finding where it lives. The problem is making the connection between 'Image Viewer' and whatever binary that actually calls.
– Ray Andrews
Feb 10 '15 at 22:42
Oh, one more thing: what do we call the 'GUI name'? 'Friendly name', 'menu name' ... what?
– Ray Andrews
Feb 11 '15 at 0:36