Wêrom't proxy-ynstellings wurkje yn in terminal mar net yn in buroblêd-starter

Jo eksportearje in proxy yn in terminal. In kommando dat dêr start wurdt, brûkt it. Klikke op it buroblêd-ikoan jout noch altyd in oare rûte. It ikoan waard gjin bern fan dat terminal.

In buroblêdsesje start applikaasjes fia syn eigen startmasjinerie. Dy prosessen ervje dat omjouwing, net elke lettere bewurking dy't yn in net-relatearre shell dien is. Dat kin in ferskil ferklearje sûnder te bewizen dat it applikaasjepakket defektyf is.

Exec is in kommandobeskriuwing, gjin shellskript

De Desktop Entry-spesifikaasje definiearret in útfierber bestân en arguminten foar Exec. It belooft gjin útwreiding fan shellfariabelen of ynboude shellkommando's.

Foar in ekstern programma dat de oanbelangjende omjouwingsfariabele lêst, kin in bewust beheind start dizze foarm hawwe:

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

Ferfang sawol it einpunt as it útfierbere bestân. Dit lit de startynfier sjen, gjin garânsje dat in willekeurich programma dy fariabele lêst. In browser mei syn eigen eksplisite proxybelied kin noch altyd in oare konfiguraasjeboarne kieze. Foar Chrome, bewarje syn proxy-argumint yn in brûkerstarter.

Skriuw net Exec=export ... en ferwachtsje net dat it buroblêd it as jo oanmeldingsshell ynterpretearret. Hâld ek de oanhellingsregels en stipe fjildkoaden fan de buroblêdynfier yn it each; it binne in oare parser.

Kontrolearje oft der wat nijs start is

Guon applikaasjes stjoere it fersyk nei in eksimplaar dat al rint. Guon ynfieringen brûke D-Bus-aktivearring, dy't syn eigen startpaad hat. In nij ikoanklik fêstiget gjin nij proses mei it krekt bewurke Exec-omjouwing.

Identifisearje it eksimplaar dat it fersyk docht en de konfiguraasje dy't it eins besit. In kontrolearre nije start kin de ferliking ferlytsje as dat nedich is. Foarkom it weromynstallearjen fan de applikaasje foardat fêststeld is dat it bedoelde omjouwing it ea berikt hat.