Why does a desktop launcher does not start my app, while command line does?
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
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
add a comment |
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
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
desktop-environment
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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.
Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx
– JCLL
Jan 23 '13 at 16:54
add a comment |
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.
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 likexlogo
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
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%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
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.
Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx
– JCLL
Jan 23 '13 at 16:54
add a comment |
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.
Your attempt is correct ! (However that raises another question that itself requires a new dedicated post).Thx
– JCLL
Jan 23 '13 at 16:54
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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 likexlogo
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
add a comment |
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.
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 likexlogo
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
add a comment |
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.
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.
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 likexlogo
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
add a comment |
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 likexlogo
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
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%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
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
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