I have this .desktop file in /home/user/.local/share/applications
[Desktop Entry]
Categories=AudioVideo;Video;
Comment=This Bash script compresses the specified video files (wildcards supported) to lossy h.264 format in an MP4 container
Exec="\\$HOME/Scripts/Git/compress2mp4.sh" %F
GenericName=Batch compress to mp4
Icon=folder-video
MimeType=video/x-msvideo;video/quicktime;video/mpeg;video/mp4;
Name=Compress to mp4
NoDisplay=false
Path=
StartupNotify=true
Terminal=true
TerminalOptions=\s--noclose
Type=Application
Version=1.0
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=
which shows up in the "Open with" menu and works flawlessly.
Then I created another .desktop file and copied it in /home/user/.local/share/kservices5/ServiceMenus
[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=video/x-msvideo;video/quicktime;video/mpeg;video/mp4;
Icon=folder-video
Actions=compress2mp4
X-KDE-Priority=TopLevel
X-KDE-StartupNotify=false
X-KDE-Submenu=Video
[Desktop Action compress2mp4]
Name=Compress to mp4
Icon=video-mp4
Exec="$HOME/Scripts/Git/compress2mp4.sh" %F
The service menu shows up but gives this error:
Could not find the program '$HOME/Scripts/Git/compress2mp4.sh'
I tried to replace $HOME with \\$HOME and ~/ but it did not help.
If I type /home/my-user-name/... instead of the $HOME there is a window opens up in the background and closes up right away so I can't catch what is going on there.
Does anyone have an idea on why a .desktop file Type=service does not work while a very similar file Type=application works?
It seems that environment variables are not evaluated by .desktop file processors, as evidenced by similar problems posted online. If anything, it looks that KDE understanding environment variable in /home/user/.local/share/applications is a bug.
For one possible workaround, see this StackOverflow post. Personally, I created service menu with following entry and it did work as expected (pay attention to placement of quotation marks):
Exec=sh -c "$HOME/bin/test.sh %F"
If I use absolute path to script in Exec, it does show something that could be mistaken for "window in background". Name of process appears on taskbar (which usually shows only windows) and quickly disappears. In my case, that was because my test script had only one command inside and finished execution almost instantaneous. How long do you expect your program to run? Have you verified that it does not finish successfully?
If you don't want to use sh workaround and don't want to use absolute path inside .desktop file, consider placing your script in one of directories in $PATH, where .desktop file processor will look for it. You can see value of that variable from plasma point of view by using following command:
tr '\0' '\n' < /proc/$(pidof plasmashell)/environ
Related
I am currently working on a Raspberry Pi. I want to implement a script to run a Python program at startup. I followed the steps given in this guide. The contents of my script are:
#! /bin/sh
# /etc/init.d/launchScript
cd path/to/file
python main.py
Although the script successfully runs at startup (file and I/O operations are working), but the terminal window doesn't appear. I am not able to debug any errors at all.
Can anyone help me on how to make the terminal appear so that debugging is possible?
From a forum post;
create a .desktop file, Ex. myApp.desktop
myApp.desktop file content:
[Desktop Entry]
Exec=lxterminal -e "/home/pi/main.py"
Type=Application
Than, copy myApp.destop to ~/.config/autostart directory.
I typically write a shell script like this:
#!/bin/sh
nohup /path/to/myapp -test "$#" &
I can then launch this shell script from terminal and any command line arguments I give it are passed to the shell script which are then passed to the exec line myapp. I am using Ubuntu, and the issue is with shell script the icon of the launced up is not that of the shell file. It uses the default icon of the myapp. That's why I am moving to .desktop, it makes the launched app use the icon of the .desktop file.
I have written a .desktop file per:
[Desktop Entry]
Name=My Ro
Type=Application
Comment=Web Application
Exec=/path/to/myapp -test #
Icon=/opt/giteye/icon.xpm
Name[en_US]=My Ro
I put an # sign on the exec line, but its not working as expected. It is not taking the command line arguments I give to the .desktop and its not putting it into the exec line. Can you please help me to pass the command line arguments received by the .desktop to the Exec line/
What you want -- to open desktop files from the terminal with arbitrary arguments -- is not how .desktop files are used.
Only certain variables are allowed in the arguments, essentially corresponding to desktop-like actions: files to open, and so forth. If that's what you want, you may be able to do it using codes like %f for a file, and then using the UI to drag a file onto the application, for example.
Another way to configure an application is to use Desktop Actions, which essentially are an enumerated list of ways to open an application. So if you have a well-defined set of arguments you want to use, that would work.
See the Desktop Entry specification for details on the argument codes and how desktop actions work.
I have lots of programs installed, for each one I append its directory to the $PATH variable.
this is easy, I open a terminal type the name and it runs, until I decided to make a desktop file for each program. It seems desktop files do not recognize the $PATH variable
[Desktop Entry]
Version=1.0
Terminal=false
Icon=/usr/share/applications/ISE.png
Type=Application
Categories=Digital
Exec=ise
Name=Xilinx ISE
It does not even appear in unity menu, the command ise usually works fine in a terminal, I also tried to use the complete /path/to/ise, still does not appear in search.
but if I remove ise and put for example gedit instead. it appears in search, opens gedit and works fine. how do I make Desktop files recognize the $PATH variable and execute these commands ??
I've made a script like so:
#! /bin/bash
/path/to/program
and made it executable. I want to be able to double click on it in Nautilus, choose "run in terminal" and everything should be the same as when I invoke the script myself from the terminal, where it works fine. When I double click though, I get the error message "error while loading shared libraries: libpylonbase-2.3.3.so: cannot open shared object file: No such file or directory" and the terminal closes immediately. libpylonbase-2.3.3 has to do with an industrial camera that is used within the program. Can anyone see the reason for it working it one of the cases and not in the other?
Check that the environment variables are the same when you run your program from the terminal and from Nautilus. You can do this by inserting the following line:
env > /tmp/test
At least $PATH and $LD_LIBRARY_PATH should be the same.
It's probably LD_LIBRARY_PATH this time, but you can track down env var differences automatically using http://stromberg.dnsalias.org/~strombrg/env-search.html
I want to write a script for linux, that will first copy a movie/series file to cache with something like:
cat /filepath/filename > /dev/null
and than open the same file in vlc.
The problem is getting the file name and path in to the script. I would like to simply double click a file, or somehow make this a faster process than typing this manually (especially because the file names of some series are just inconsistent and hard to type, even with auto-complete).
This is useful for watching movies or series on a laptop/netbook, since it allows the disk to spin down.
You should be able to create your own 'program' in a bash script which takes its first argument to be the filename using the convention "$1".
The bash script should look something like the below. I tested it, storing the script in the file cachedvlc.sh. The inverted commas helping to handle whitespace and weird characters...
#!/bin/bash
cat "$1" > /dev/null
vlc "$1"
...and will need to be made executable by changing its permissions through the file manager or running this in the terminal...
chmod u+x cachedvlc.sh
Then within your operating system, associate your bash script with the type of file you want to launch. For example on Ubuntu, you could add your script and call it 'Cached VLC' to the Menu using the 'Main Menu' application, then right-click on the file in Nautilus and choose 'Open with' to select your bash script.
After this, double-clicking or right-clicking on a file within your filemanager should be good enough to launch a cached view. This assumes what you say about caching is in fact correct, which I can't easily check.