Hvorfor proxyinnstillinger virker i en terminal men ikke i en skrivebordsstarter

Du eksporterer en proxy i en terminal. En kommando som startes der, bruker den. Et klikk på skrivebordsikonet gir fortsatt en annen rute. Ikonet ble ikke et barn av den terminalen.

En skrivebordsøkt starter programmer gjennom sin egen startmekanisme. Disse prosessene arver det miljøet, ikke hver senere endring som er gjort i et urelatert skall. Det kan forklare en forskjell uten å bevise at programpakken er defekt.

Exec er en kommandobeskrivelse, ikke et skallskript

Desktop Entry-spesifikasjonen definerer en kjørbar fil og argumenter for Exec. Den lover ikke utvidelse av skallvariabler eller innebygde skallkommandoer.

For et eksternt program som leser den relevante miljøvariabelen, kan en bevisst avgrenset start ha denne formen:

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

Erstatt både endepunktet og den kjørbare filen. Dette viser startinndataene, ikke en garanti for at en vilkårlig applikasjon leser den variabelen. En nettleser med sin egen uttrykkelige proxy-policy kan fortsatt velge en annen konfigurasjonskilde. For Chrome, lagre proxyargumentet i en brukerstarter.

Ikke skriv Exec=export ... og forvent at skrivebordet tolker det som innloggingsskallet ditt. Ha også skrivebordsoppføringens regler for anførselstegn og støttede feltkoder i tankene; de er en annen parser.

Kontroller om noe nytt ble startet

Noen programmer sender forespørselen til en forekomst som allerede kjører. Noen oppføringer bruker D-Bus-aktivering, som har sin egen startvei. Et nytt ikonklikk etablerer ikke en fersk prosess med det nettopp redigerte Exec-miljøet.

Identifiser forekomsten som sender forespørselen, og konfigurasjonen den faktisk eier. En kontrollert fersk start kan snevre inn sammenligningen når det er hensiktsmessig. Unngå å installere programmet på nytt før du har fastslått at det tiltenkte miljøet noen gang nådde det.