name of binary vs. name in GUI












1















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 :-(










share|improve this question

























  • 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
















1















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 :-(










share|improve this question

























  • 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














1












1








1








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 :-(










share|improve this 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 :-(







debian xfce gui desktop mime-types






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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



















  • 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

















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










2 Answers
2






active

oldest

votes


















0














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.






share|improve this answer

































    0














    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






    share|improve this answer























      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      0














      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.






      share|improve this answer






























        0














        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.






        share|improve this answer




























          0












          0








          0







          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 13 '17 at 12:36









          Community

          1




          1










          answered Jul 23 '15 at 17:43









          GillesGilles

          540k12810931606




          540k12810931606

























              0














              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






              share|improve this answer




























                0














                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






                share|improve this answer


























                  0












                  0








                  0







                  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






                  share|improve this answer













                  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







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 10 '15 at 22:19









                  CostasCostas

                  12.7k1129




                  12.7k1129






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

                      is 'sed' thread safe

                      How to make a Squid Proxy server?