python programma start niet op vanuit .desktop file

[peer]

os: debian 11 xfce
Ik heb een python bestand 'shutdown.py' gemaakt als hulpje om de pc af te sluiten.
Als ik dit programma start door te dubbelklikken in de filemanager of door te starten in de terminal dan werkt het zonder problemen.
Als ik dit programma wil starten vanuit het menu met een .desktop file dan werkt het niet. Ik heb als een workaround een scriptje met twee regels gemaakt:

Code: [Selecteer]

#!/bin/bash
cd "/home/acer/Scripts/"
/home/acer/Scripts/shutdown.py
Als ik dit script gebruik in mijn .desktopfile dan werkt het wel.
vragen:
1. Kan ik het .desktopfile aanpasssen zodat de directory van het python bestand gebruikt wordt als workdriectory?
2. Kan ik het python bestand aanpassen zodat  het bestand vanuit elke directory kan worden opgestart?

bijgesloten: zipbestand met daarin shutdown.py, shutdown.png, shutdown.sh en shutdown.desktop

[MKe]

Ik denk dat je het Python script moet opstarten met Python.

Verder moet je in je Python script de active directory instellen met os.chdir.

[peer]

het programma opstarten met python heb ik geprobeerd maar werkt ook niet.
Ik denk dat het programma niet opstart doordat in het programma het image shutdown.png wordt geladen en dat dit image niet gevonden kan worden.

Het instellen van de actieve directory (workdirectory) met het commando os.chdir lijkt mij een antwword op min vraag. Even uitzoeken hoe ik dat precies kan doen.

In Kde Plasma geef ik bij het maken van de .desktop file gewoon op wat de workdirectory moet zijn en dan  werkt het gewoon. Dit gaat gewoon grafisch in de menu-editor. In xfce weet ik niet hoe dat moet

[peer]

het commando os.chdir werkt. Ik heb nu de workdirectory 'hardcoded' in het programma staan

Code: [Selecteer]

import os
os.chdir("/home/acer/Scripts/"Nu kan ik in de .desktopfile gewoon het programma /home/acer/Scripts/shutdown.py starten en het werkt.

Alleen wil ik nu nog van de hardcoding af. Daar kom ik nog wel uit.

En de vraag blijft nog staan hoe ik in xfce in een .desktopfile de workdirectory kan vastleggen

[vanadium]

Het is zowiezo eigenaardig dat een script om af te sluiten moet opgestart worden met de directory waar het script zich bevindt als actieve directory. Daarvoor zal je eens je script zelf moeten bekijken: je doet daar iets op een manier die wellicht beter kan.

In  een .desktop bestand kan je een actieve directory instellen met een "Path="  lijn.

[peer]

de Path=... regel heb ik net ook ontdekt. Daarmee wordt de workdirectory ingesteld. Dat werkt en zorgt ervoor dat ik geen hardcoding in het python-programma hoef te gebruiken.

De hardcoding is nodig omdat in het programma een icon gebruikt wordt dat inzelfde directory staat als het programma. Als ik het programma start vanuit een  .desktop file dan is de workdirectory mijn home-directory. Maar het programma staat in een subdirectory dus kan het icon niet gevonden worden en het programma wil niet starten.

het programma zelf laten opzoeken in welke directory de bestanden staat als het een andere workdirectory heeft is best wel lastig 

[vanadium]

Als het werkt, werkt het, maar je kan wellicht wel vrij gemakkelijk het path van het uitvoerbare bestand vanuit je script bepalen, zodat het geen rol meer speelt waar je het script installeert en hoe je het aanroept. Eens voor een regenachtige zondagnamiddag...

[Bloom]

Je kunt in een script de huidige directory opvragen via de environment variable $PWD.
Je eigen home directory is $HOME.
Het complete opgegeven pad en de naam van het gestarte bash-script kan opgevraagd worden via $0.
Als je het script met ./ hebt gestart, zal het pad ook ./ zijn. Wil je het echte volledige pad, ongeacht vanwaar het script gestart werd, dan kun je dat met deze oneliner:

Code: [Selecteer]

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
en $SCRIPT_DIR bevat dan het volledige absolute pad naar het script.

[peer]

weer een hoop om over na te denken.

In python heb ik het volgende gevonden:

Code: [Selecteer]

os.path.dirname(__file__)Dit commando geeft het pad van het momenteel actieve programma. In mijn geval dus het pad van het programma shutdown.py
Met het volgende commando kan ik nu de workdirectory aanpassen:

Code: [Selecteer]

os.chdir(os.path.dirname(__file__))En dit werkt!!

[MKe]

Heel goed

[Bloom]

[peer]

Je kunt in een script de huidige directory opvragen via de environment variable $PWD.
Je eigen home directory is $HOME.
Het complete opgegeven pad en de naam van het gestarte bash-script kan opgevraagd worden via $0.
Als je het script met ./ hebt gestart, zal het pad ook ./ zijn. Wil je het echte volledige pad, ongeacht vanwaar het script gestart werd, dan kun je dat met deze oneliner:

Code: [Selecteer]

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
en $SCRIPT_DIR bevat dan het volledige absolute pad naar het script.

ik heb nog even gekeken naar deze oneliner. Hij werkt inderdaad. Maar ik snap niet goed wat er gebeurt. Bloom, kun je dit misschien uitleggen??

[Bloom]

Natuurlijk. Als we van binnen naar buiten werken, zie je ${BASH_SOURCE[0]} staan. Dat is eigenlijk hetzelfde als $0. Het geeft het pad en de bestandsnaam van het huidige draaiende script.
De dirname ervoor geeft alleen het pad. De '--' na dirname zegt dat er hierna geen opties meer volgen. Als het script gestart was met ./, dan krijg je als pad ook . terug.
Daarom proberen we een cd uit (ook hier dient de -- om te zeggen dat er geen opties meer volgen) en als die lukt, gebruiken we pwd om de juiste naam van de directory te halen. In plaats van . krijg je nu /home/gebruiker/. Als de cd niet lukt, is de directorynaam niet geldig en vermits we die van het systeem haalden zou dat eigenlijk niet mogen voorkomen, maar dan zal het resultaat leeg zijn. Omdat die cd in een subshell gebeurt, verandert er dus niets in het script zelf en blijft die in dezelfde directory staan als voorheen .

[peer]

Jam het koste me even wat tijd maar nu begrijp ik het.
Bedank voor de uitleg!!!