Je exporteert een proxy in een terminal. Een opdracht die daar start, gebruikt hem. Klikken op het bureaubladpictogram geeft nog steeds een andere route. Het pictogram is geen kind van die terminal geworden.

Een bureaubladsessie start toepassingen via zijn eigen startmechanisme. Die processen erven die omgeving, niet elke latere wijziging die in een niet-gerelateerde shell is gemaakt. Dat kan een verschil verklaren zonder te bewijzen dat het toepassingspakket defect is.

Exec is een opdrachtbeschrijving, geen shellscript

De Desktop Entry-specificatie definieert een uitvoerbaar bestand en argumenten voor Exec. Ze belooft geen shellvariabele-expansie en geen ingebouwde shellopdrachten.

Voor een extern programma dat de betreffende omgevingsvariabele leest, kan een bewust beperkte start deze vorm hebben:

Exec=env https_proxy=http://proxy.example:8080 /path/to/application

Vervang zowel het eindpunt als het uitvoerbare bestand. Dit toont de startinvoer, niet de garantie dat een willekeurige toepassing die variabele leest. Een browser met zijn eigen expliciete proxybeleid kan nog steeds een andere configuratiebron kiezen. Voor Chrome, sla zijn proxyargument op in een gebruikersstarter.

Schrijf niet Exec=export ... en verwacht niet dat het bureaublad dat als je login-shell interpreteert. Houd ook de aanhalingstekenregels en ondersteunde veldcodes van de bureaubladvermelding in het oog; het zijn een andere parser.

Controleer of er iets nieuws is gestart

Sommige toepassingen sturen het verzoek naar een al draaiende instantie. Sommige vermeldingen gebruiken D-Bus-activering, die een eigen startpad heeft. Een nieuwe pictogramklik legt geen vers proces aan met de zojuist bewerkte Exec-omgeving.

Identificeer de instantie die het verzoek doet en de configuratie die zij werkelijk bezit. Een gecontroleerde verse start kan de vergelijking verkleinen wanneer dat passend is. Vermijd het opnieuw installeren van de toepassing voordat is vastgesteld of de bedoelde omgeving haar ooit heeft bereikt.

Gerelateerde artikelen