Kvifor verkar proxyinnstillingar i ein terminal men ikkje i ein skrivebordsstartar

Du eksporterer ein proxy i ein terminal. Ein kommando som vert starta der, brukar han. Eit klikk på skrivebordsikonet gjev framleis ei anna rute. Ikonet vart ikkje eit barn av den terminalen.

Ei skrivebordsøkt startar program gjennom sin eigen startmekanisme. Dei prosessane arvar det miljøet, ikkje kvar seinare endring som er gjord i eit urelatert skall. Det kan forklare ein skilnad utan å prova at programpakka er defekt.

Exec er ei kommandoskildring, ikkje eit skallskript

Desktop Entry-spesifikasjonen definerer ei køyrbar fil og argument for Exec. Han lovar ikkje utviding av skallvariablar eller innebygde skallkommandoar.

For eit eksternt program som les den relevante miljøvariabelen, kan ein medvite avgrensa start ha denne forma:

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

Byt ut både endepunktet og den køyrbare fila. Dette viser startinndataa, ikkje ei garanti for at eit vilkårleg program les den variabelen. Ein nettlesar med sin eigen uttrykkelege proxy-policy kan framleis velja ei anna konfigurasjonskjelde. For Chrome, lagre proxyargumentet hans i ein brukarstartar.

Ikkje skriv Exec=export ... og vent at skrivebordet tolkar det som innloggingsskalet ditt. Ha òg reglane for hermeteikn og støtta feltkoder i skrivebordsoppføringa i tankane; dei er ein annan parser.

Kontroller om noko nytt vart starta

Nokre program sender førespurnaden til ein førekomst som alt køyrer. Nokre oppføringar brukar D-Bus-aktivering, som har sin eigen startveg. Eit nytt ikonklikk etablerer ikkje ein fersk prosess med det nettopp redigerte Exec-miljøet.

Identifiser førekomsten som sender førespurnaden, og konfigurasjonen han faktisk eig. Ein kontrollert fersk start kan snevra inn samanlikninga når det høver. Unngå å installera programmet på nytt før du har fastslått at det tiltenkte miljøet nokosinne nådde det.