Varför proxyinställningar fungerar i en terminal men inte i en skrivbordsstartare

Du exporterar en proxy i en terminal. Ett kommando som startas där använder den. Ett klick på skrivbordsikonen ger ändå en annan väg. Ikonen blev inte ett barn till den terminalen.

En skrivbordssession startar program genom sin egen startmekanism. De processerna ärver den miljön, inte varje senare ändring som gjorts i ett orelaterat skal. Det kan förklara en skillnad utan att bevisa att programpaketet är defekt.

Exec är en kommandobeskrivning, inte ett skalskript

Desktop Entry-specifikationen definierar en körbar fil och argument för Exec. Den lovar inte expansion av skalvariabler eller inbyggda skalkommandon.

För ett externt program som läser den relevanta miljövariabeln kan en medvetet avgränsad start ha denna form:

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

Ersätt både slutpunkten och den körbara filen. Detta visar startens indata, inte en garanti för att ett godtyckligt program läser den variabeln. En webbläsare med egen uttrycklig proxypolicy kan fortfarande välja en annan konfigurationskälla. För Chrome, spara dess proxyargument i en användarstartare.

Skriv inte Exec=export ... och förvänta dig att skrivbordet tolkar det som ditt inloggningsskal. Håll också skrivbordspostens citatregler och stödda fältkoder i åtanke; de är en annan parser.

Kontrollera om något nytt startades

Vissa program skickar begäran till en instans som redan körs. Vissa poster använder D-Bus-aktivering, som har sin egen startväg. Ett nytt ikonklick etablerar inte en färsk process med den nyss redigerade Exec-miljön.

Identifiera instansen som gör begäran och konfigurationen som den faktiskt äger. En kontrollerad färsk start kan snäva in jämförelsen när det är lämpligt. Undvik att installera om programmet innan du fastställt om den avsedda miljön någonsin nådde det.