Software Versions:
Debian GNU/Linux 10 (Buster)
Kernel 4.19.0-27-686-pae
GNOME Shell 3.30.2
alacarte/oldstable,now 3.11.91-4 all
Symptom:
I have successfully used alacarte (Main Menu on Debian) to add a menu called Backups and Items under Backups for each set of data to backup (my home/user directories, My NAS directories...). When I left-click on Applications (on the topmost bar that contains the current date/time) the dropdown menu looks great, the Backups menu and all of it's items look great. If I hover over the Backups entry in the left column all of the items appear in the right colun, everything looks great. When I click on a backup item I just get returned to the desktop, nothing is executed (seemingly).
Details:
the application that I'm trying to run is a Python app that I wrote called rsync-backup.py that is stored in the rsync_backup directory in my home /user directory. the command that I'm trying to run (in the Exec key of the desktop file is /home/<user>/rsync_backup/rsync-backup.py job-mitch-nas.job. Notice the inclusion of the argument on the "command line". Inclusion of the argument is different from 99.9% of the other menu items that work properly.
What I've tried:
I have tried several things with no success in being able to execute the command rsync-backup.py <argument> from the menu. I have tried the following:
Created a BASH shell script to run rsync-backup.py thru fails from the menu, Runs fine in the terminal, running the rsync-backup.py directly runs fine.
Determined the specific .local/share/applications/alacarte-made .desktop file and added Path, Hidden, NoDisplay keys with path-to-executable, false, false values. Path= is the line before Exec=.
Experimented with %f on the Exec= line, both before and after the argument. No change. I don't know exactly how to use %f correctly.
I'm at a total loss. The only thing I can think of is; due to all of my attempts at a fix I now have 40+ alacarte-made-(1 ... 40+).desktop files in my /home/mitcon/.local/share/applications directory. I'm not sure if I can manually delete any of these ,desktop files. alacarte did not delete any .desktop file when I deleted the item there.
Any ideas are MORE than welcome!
Thanks
Problem running application in GNOME.
Re: Problem running application in GNOME.
Here are the contents of alacarte-made-45.desktop. it is linked to the "Test rsync-backup" item in the Backups category and exhibits the problem I'm talking about.
[Desktop Entry]
Comment=
Terminal=false
Name=Test rsync-backup
Path=/home/mitcon/rsync_backup/
Exec=/home/mitcon/rsync_backup/rsync-backup.py job-mitch-nas.job
Type=Application
Icon=gnome-panel-launcher
NoDisplay=false
Hidden=false
It fails to launch with or without the "Path=" key. Same thing for the "NoDisplay=" and "Hidden=" keys. It also appears that, when created with alacarte there should be no need for the "Path=" key.
Do you use alacarte? If so, do you know if there is any negative implications to removing any of the alacarte-made-x.desktop (x in my case is 1..45) files that are not needed? I hate having unneeded ones hanging around.
Thanks for any insight that you may have...
[Desktop Entry]
Comment=
Terminal=false
Name=Test rsync-backup
Path=/home/mitcon/rsync_backup/
Exec=/home/mitcon/rsync_backup/rsync-backup.py job-mitch-nas.job
Type=Application
Icon=gnome-panel-launcher
NoDisplay=false
Hidden=false
It fails to launch with or without the "Path=" key. Same thing for the "NoDisplay=" and "Hidden=" keys. It also appears that, when created with alacarte there should be no need for the "Path=" key.
Do you use alacarte? If so, do you know if there is any negative implications to removing any of the alacarte-made-x.desktop (x in my case is 1..45) files that are not needed? I hate having unneeded ones hanging around.
Thanks for any insight that you may have...
Re: Problem running application in GNOME.
No, I use don't use alacarte. I have no Gnome but KDE Plasma and in the rare case I need a .desktop file I create it by hand. But I don't think deleting these files has a negative impact.
I tried your modified example in KDE and it work:
~/.local/share/applications/script.desktop
~/script.py with x bits set (chmod +x script.py)
Clicking on the item in the application menu, then checking it wrote the file:
You could try if this simple example works for you.
I tried your modified example in KDE and it work:
~/.local/share/applications/script.desktop
Code: Select all
[Desktop Entry]
Comment=
Terminal=false
Name=Test rsync-backup
Path=~
Exec=~/script.py job-mitch-nas.job
Type=Application
Icon=gnome-panel-launcher
NoDisplay=false
Hidden=false
Code: Select all
#!/usr/bin/env python3
import sys
import os
def main():
file_path = os.path.expanduser('~/test_args.txt')
with open(file_path, 'w') as f:
f.write(sys.argv[1])
if __name__ == '__main__':
main()
Code: Select all
~$ cat test_args.txt
job-mitch-nas.job
Re: Problem running application in GNOME.
Thanks for the reply. Will try tomorrow. Although alacarte was developed under the freedesktop.org spec, and is supposed to work under KDE, GNOME, etal... I'm thinking it may still not work.
I'm thinking it has something to do with supplying a parameter on the command line. I think i may need to do a loader that takes no parameter but rather the user selects the job or queue file from a list box containing all the Job/queue files found in the rsync_backup directory.
Thanks for your help, will let you know.
I'm thinking it has something to do with supplying a parameter on the command line. I think i may need to do a loader that takes no parameter but rather the user selects the job or queue file from a list box containing all the Job/queue files found in the rsync_backup directory.
Thanks for your help, will let you know.
Re: Problem running application in GNOME.
Blackbird:
Tried your suggestions, got the same result as before. I'm beginning to think its a problem handling a commandline with a parameter.
Going to write a BASH wrapper, using YAD to present a listbox to present jobs/ques on the system, which can then be selected. This will eliminate a commandline argument, being included in the .desktop file. "rsync-backup job-mitcch-nas.job" will then be executed via the BASH wrapper.
Man, I hate cludges!!!
Thanks
Tried your suggestions, got the same result as before. I'm beginning to think its a problem handling a commandline with a parameter.
Going to write a BASH wrapper, using YAD to present a listbox to present jobs/ques on the system, which can then be selected. This will eliminate a commandline argument, being included in the .desktop file. "rsync-backup job-mitcch-nas.job" will then be executed via the BASH wrapper.
Man, I hate cludges!!!
Thanks
Re: Problem running application in GNOME.
The changes I did in the .desktop file are only for calling my test script instead your script which I don't have.
I would try the script I added previously to check if command line parameter are correctly given to your script from your application starter. If the "test_args.txt" is created and the content is the command line argument, then it works and the problem is elsewhere.
If this works or not, it would be good to add logging to your backup script where you log when the script was called, what the command line parameter was and what error happened during execution.
Edit:
Here a script variant that uses logging:
I would try the script I added previously to check if command line parameter are correctly given to your script from your application starter. If the "test_args.txt" is created and the content is the command line argument, then it works and the problem is elsewhere.
If this works or not, it would be good to add logging to your backup script where you log when the script was called, what the command line parameter was and what error happened during execution.
Edit:
Here a script variant that uses logging:
Code: Select all
#!/usr/bin/env python3
import sys
import os
import logging
from datetime import datetime
def main():
log_file_path = os.path.expanduser('~/script.log')
logging.basicConfig(
filename=log_file_path,
level=logging.DEBUG,
format='%(asctime)s - %(levelname)s - %(message)s'
)
logging.info(f'Script: {sys.argv[0]}')
logging.info(f'Command line arguments: {sys.argv}')
logging.info(f'Current working directory: {os.getcwd()}')
if __name__ == '__main__':
main()