Hvorfor proxyindstillinger virker i en terminal men ikke i en skrivebordsstarter

Du eksporterer en proxy i en terminal. En kommando, der startes der, bruger den. Et klik på skrivebordsikonet giver stadig en anden rute. Ikonet blev ikke et barn af den terminal.

En skrivebordssession starter programmer gennem sin egen startmekanisme. De processer arver det miljø, ikke enhver senere ændring foretaget inde i en urelateret shell. Det kan forklare en forskel uden at bevise, at programpakken er defekt.

Exec er en kommandobeskrivelse, ikke et shell-script

Desktop Entry-specifikationen definerer en eksekverbar fil og argumenter for Exec. Den lover ikke udvidelse af shell-variabler eller indbyggede shell-kommandoer.

For et eksternt program, der læser den relevante miljøvariabel, kan en bevidst afgrænset start have denne form:

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

Erstat både endepunktet og den eksekverbare fil. Det viser startinputtet, ikke en garanti for, at en vilkårlig applikation læser den variabel. En browser med sin egen udtrykkelige proxypolitik kan stadig vælge en anden konfigurationskilde. For Chrome skal du gemme dens proxyargument i en brugerstarter.

Skriv ikke Exec=export ... og forvent, at skrivebordet fortolker det som din login-shell. Hold også skrivebordspostens citationstegnsregler og understøttede feltkoder for øje; de er en anden parser.

Kontroller, om noget nyt blev startet

Nogle programmer sender anmodningen til en instans, der allerede kører. Nogle poster bruger D-Bus-aktivering, som har sin egen startvej. Et nyt ikonklik etablerer ikke en frisk proces med det netop redigerede Exec-miljø.

Identificer den instans, der sender anmodningen, og den konfiguration, den faktisk ejer. En kontrolleret frisk start kan indsnævre sammenligningen, når det er passende. Undgå at geninstallere programmet, før det er fastslået, at det tilsigtede miljø nogensinde nåede det.