Why does a desktop launcher does not start my app, while command line does?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2















I installed a (proprietary) software in /opt and I am able to run it perfectly using command line. Then I'd like to create a desktop icon to launch it : on my Mint distro I use "create_launcher"



However, when clicking on my fresh icon, nothing happens. Why ?










share|improve this question
























  • Did you specify the full path? Is the program executable?

    – user1146332
    Jan 22 '13 at 10:55











  • Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

    – taffer
    Jan 22 '13 at 11:27















2















I installed a (proprietary) software in /opt and I am able to run it perfectly using command line. Then I'd like to create a desktop icon to launch it : on my Mint distro I use "create_launcher"



However, when clicking on my fresh icon, nothing happens. Why ?










share|improve this question
























  • Did you specify the full path? Is the program executable?

    – user1146332
    Jan 22 '13 at 10:55











  • Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

    – taffer
    Jan 22 '13 at 11:27













2












2








2








I installed a (proprietary) software in /opt and I am able to run it perfectly using command line. Then I'd like to create a desktop icon to launch it : on my Mint distro I use "create_launcher"



However, when clicking on my fresh icon, nothing happens. Why ?










share|improve this question
















I installed a (proprietary) software in /opt and I am able to run it perfectly using command line. Then I'd like to create a desktop icon to launch it : on my Mint distro I use "create_launcher"



However, when clicking on my fresh icon, nothing happens. Why ?







desktop-environment






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 22 '13 at 11:42







JCLL

















asked Jan 22 '13 at 10:53









JCLLJCLL

11315




11315












  • Did you specify the full path? Is the program executable?

    – user1146332
    Jan 22 '13 at 10:55











  • Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

    – taffer
    Jan 22 '13 at 11:27

















  • Did you specify the full path? Is the program executable?

    – user1146332
    Jan 22 '13 at 10:55











  • Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

    – taffer
    Jan 22 '13 at 11:27
















Did you specify the full path? Is the program executable?

– user1146332
Jan 22 '13 at 10:55





Did you specify the full path? Is the program executable?

– user1146332
Jan 22 '13 at 10:55













Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

– taffer
Jan 22 '13 at 11:27





Maybe you want to read this article about how .desktop files work. If everything is set up correctly it should work.

– taffer
Jan 22 '13 at 11:27










2 Answers
2






active

oldest

votes


















3














this is mostly a comment but could become an answer. we really need more information to be able to help you.



please post:



  • your "command line" environment (the output of set when using
    bash),

  • the content of the .desktop file of your created launcher (most likely found in ~/Desktop) and

  • the exact shell commands leading up to the program start correctly.

  • the output of file /opt/the/programm/youre/attempting/to/run

  • the content of /opt/the/programm/youre/attempting/to/run IF the output of find does not contain the word "binary". However there may be copyright/licensing issues with that!

A wild attempt at an answer without any of the above information:



Your software installed in /opt/... is not a statically linked binary but requires some libraries which are also installed below /opt but your system does not know to search that directoy for required libraries. One way to fix this is setting the LD_LIBRARY_PATH variable to include your directory in /opt.






share|improve this answer























  • Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

    – JCLL
    Jan 23 '13 at 16:54


















0














You most probably did not specify a specific path and the binary is therefore searched using the $PATH variable.



It seems like your location "/opt/..." is contained in your shells PATH but not in your launchers path. This is probably because you set it in the config file of your shell, like .bashrc.



The easiest solution is simply specifying the complete path in your launcher, i.e. /opt/path/to/your/binary.






share|improve this answer























  • No, using the full path does not solve the issue

    – JCLL
    Jan 22 '13 at 11:41











  • in fact it is not a binary, but a small script...

    – JCLL
    Jan 22 '13 at 11:43











  • In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

    – michas
    Jan 22 '13 at 11:47











  • It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

    – Danny Staple
    Jan 22 '13 at 12:37











  • If it is a script: Where should it put the output? Launching it in an x-term could work.

    – Bonsi Scott
    Jan 22 '13 at 18:39










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%2f62147%2fwhy-does-a-desktop-launcher-does-not-start-my-app-while-command-line-does%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









3














this is mostly a comment but could become an answer. we really need more information to be able to help you.



please post:



  • your "command line" environment (the output of set when using
    bash),

  • the content of the .desktop file of your created launcher (most likely found in ~/Desktop) and

  • the exact shell commands leading up to the program start correctly.

  • the output of file /opt/the/programm/youre/attempting/to/run

  • the content of /opt/the/programm/youre/attempting/to/run IF the output of find does not contain the word "binary". However there may be copyright/licensing issues with that!

A wild attempt at an answer without any of the above information:



Your software installed in /opt/... is not a statically linked binary but requires some libraries which are also installed below /opt but your system does not know to search that directoy for required libraries. One way to fix this is setting the LD_LIBRARY_PATH variable to include your directory in /opt.






share|improve this answer























  • Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

    – JCLL
    Jan 23 '13 at 16:54















3














this is mostly a comment but could become an answer. we really need more information to be able to help you.



please post:



  • your "command line" environment (the output of set when using
    bash),

  • the content of the .desktop file of your created launcher (most likely found in ~/Desktop) and

  • the exact shell commands leading up to the program start correctly.

  • the output of file /opt/the/programm/youre/attempting/to/run

  • the content of /opt/the/programm/youre/attempting/to/run IF the output of find does not contain the word "binary". However there may be copyright/licensing issues with that!

A wild attempt at an answer without any of the above information:



Your software installed in /opt/... is not a statically linked binary but requires some libraries which are also installed below /opt but your system does not know to search that directoy for required libraries. One way to fix this is setting the LD_LIBRARY_PATH variable to include your directory in /opt.






share|improve this answer























  • Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

    – JCLL
    Jan 23 '13 at 16:54













3












3








3







this is mostly a comment but could become an answer. we really need more information to be able to help you.



please post:



  • your "command line" environment (the output of set when using
    bash),

  • the content of the .desktop file of your created launcher (most likely found in ~/Desktop) and

  • the exact shell commands leading up to the program start correctly.

  • the output of file /opt/the/programm/youre/attempting/to/run

  • the content of /opt/the/programm/youre/attempting/to/run IF the output of find does not contain the word "binary". However there may be copyright/licensing issues with that!

A wild attempt at an answer without any of the above information:



Your software installed in /opt/... is not a statically linked binary but requires some libraries which are also installed below /opt but your system does not know to search that directoy for required libraries. One way to fix this is setting the LD_LIBRARY_PATH variable to include your directory in /opt.






share|improve this answer













this is mostly a comment but could become an answer. we really need more information to be able to help you.



please post:



  • your "command line" environment (the output of set when using
    bash),

  • the content of the .desktop file of your created launcher (most likely found in ~/Desktop) and

  • the exact shell commands leading up to the program start correctly.

  • the output of file /opt/the/programm/youre/attempting/to/run

  • the content of /opt/the/programm/youre/attempting/to/run IF the output of find does not contain the word "binary". However there may be copyright/licensing issues with that!

A wild attempt at an answer without any of the above information:



Your software installed in /opt/... is not a statically linked binary but requires some libraries which are also installed below /opt but your system does not know to search that directoy for required libraries. One way to fix this is setting the LD_LIBRARY_PATH variable to include your directory in /opt.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 22 '13 at 13:17









BananguinBananguin

5,2901338




5,2901338












  • Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

    – JCLL
    Jan 23 '13 at 16:54

















  • Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

    – JCLL
    Jan 23 '13 at 16:54
















Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

– JCLL
Jan 23 '13 at 16:54





Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx

– JCLL
Jan 23 '13 at 16:54













0














You most probably did not specify a specific path and the binary is therefore searched using the $PATH variable.



It seems like your location "/opt/..." is contained in your shells PATH but not in your launchers path. This is probably because you set it in the config file of your shell, like .bashrc.



The easiest solution is simply specifying the complete path in your launcher, i.e. /opt/path/to/your/binary.






share|improve this answer























  • No, using the full path does not solve the issue

    – JCLL
    Jan 22 '13 at 11:41











  • in fact it is not a binary, but a small script...

    – JCLL
    Jan 22 '13 at 11:43











  • In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

    – michas
    Jan 22 '13 at 11:47











  • It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

    – Danny Staple
    Jan 22 '13 at 12:37











  • If it is a script: Where should it put the output? Launching it in an x-term could work.

    – Bonsi Scott
    Jan 22 '13 at 18:39















0














You most probably did not specify a specific path and the binary is therefore searched using the $PATH variable.



It seems like your location "/opt/..." is contained in your shells PATH but not in your launchers path. This is probably because you set it in the config file of your shell, like .bashrc.



The easiest solution is simply specifying the complete path in your launcher, i.e. /opt/path/to/your/binary.






share|improve this answer























  • No, using the full path does not solve the issue

    – JCLL
    Jan 22 '13 at 11:41











  • in fact it is not a binary, but a small script...

    – JCLL
    Jan 22 '13 at 11:43











  • In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

    – michas
    Jan 22 '13 at 11:47











  • It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

    – Danny Staple
    Jan 22 '13 at 12:37











  • If it is a script: Where should it put the output? Launching it in an x-term could work.

    – Bonsi Scott
    Jan 22 '13 at 18:39













0












0








0







You most probably did not specify a specific path and the binary is therefore searched using the $PATH variable.



It seems like your location "/opt/..." is contained in your shells PATH but not in your launchers path. This is probably because you set it in the config file of your shell, like .bashrc.



The easiest solution is simply specifying the complete path in your launcher, i.e. /opt/path/to/your/binary.






share|improve this answer













You most probably did not specify a specific path and the binary is therefore searched using the $PATH variable.



It seems like your location "/opt/..." is contained in your shells PATH but not in your launchers path. This is probably because you set it in the config file of your shell, like .bashrc.



The easiest solution is simply specifying the complete path in your launcher, i.e. /opt/path/to/your/binary.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 22 '13 at 11:37









michasmichas

15.3k33772




15.3k33772












  • No, using the full path does not solve the issue

    – JCLL
    Jan 22 '13 at 11:41











  • in fact it is not a binary, but a small script...

    – JCLL
    Jan 22 '13 at 11:43











  • In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

    – michas
    Jan 22 '13 at 11:47











  • It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

    – Danny Staple
    Jan 22 '13 at 12:37











  • If it is a script: Where should it put the output? Launching it in an x-term could work.

    – Bonsi Scott
    Jan 22 '13 at 18:39

















  • No, using the full path does not solve the issue

    – JCLL
    Jan 22 '13 at 11:41











  • in fact it is not a binary, but a small script...

    – JCLL
    Jan 22 '13 at 11:43











  • In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

    – michas
    Jan 22 '13 at 11:47











  • It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

    – Danny Staple
    Jan 22 '13 at 12:37











  • If it is a script: Where should it put the output? Launching it in an x-term could work.

    – Bonsi Scott
    Jan 22 '13 at 18:39
















No, using the full path does not solve the issue

– JCLL
Jan 22 '13 at 11:41





No, using the full path does not solve the issue

– JCLL
Jan 22 '13 at 11:41













in fact it is not a binary, but a small script...

– JCLL
Jan 22 '13 at 11:43





in fact it is not a binary, but a small script...

– JCLL
Jan 22 '13 at 11:43













In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

– michas
Jan 22 '13 at 11:47





In that case it is probably started, but does not display anything, because the script itself failed for another reason. Try starting something like xlogo at the beginning of your script, to verify the script itself is started.

– michas
Jan 22 '13 at 11:47













It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

– Danny Staple
Jan 22 '13 at 12:37





It is possible that the script is relying on other aspects of your shell environment that is different from when it is run via the desktop launcher. Perhaps you can add a line near the top to dump the env into a file, and then diff them?

– Danny Staple
Jan 22 '13 at 12:37













If it is a script: Where should it put the output? Launching it in an x-term could work.

– Bonsi Scott
Jan 22 '13 at 18:39





If it is a script: Where should it put the output? Launching it in an x-term could work.

– Bonsi Scott
Jan 22 '13 at 18:39

















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%2f62147%2fwhy-does-a-desktop-launcher-does-not-start-my-app-while-command-line-does%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 check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay