Dlaczego ustawienia proxy działają w terminalu, ale nie w programie startowym pulpitu

Eksportujesz proxy w terminalu. Uruchomione tam polecenie go używa. Kliknięcie ikony pulpitu nadal daje inną trasę. Ikona nie stała się potomkiem tego terminala.

Sesja pulpitu uruchamia aplikacje przez własny mechanizm uruchamiania. Te procesy dziedziczą tamto środowisko, a nie każdą późniejszą zmianę wykonaną w niepowiązanej powłoce. To może wyjaśnić różnicę, nie dowodząc, że pakiet aplikacji jest wadliwy.

Exec to opis polecenia, a nie skrypt powłoki

Specyfikacja Desktop Entry definiuje plik wykonywalny i argumenty dla Exec. Nie obiecuje rozwinięcia zmiennych powłoki ani wbudowanych poleceń powłoki.

Dla programu zewnętrznego, który odczytuje odpowiednią zmienną środowiskową, celowo ograniczone uruchomienie może mieć taką postać:

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

Zastąp zarówno punkt końcowy, jak i plik wykonywalny. Pokazuje to dane wejściowe uruchomienia, a nie gwarancję, że dowolna aplikacja odczyta tę zmienną. Przeglądarka z własną jawną polityką proxy nadal może wybrać inne źródło konfiguracji. W przypadku Chrome zapisz jego argument proxy w programie startowym użytkownika.

Nie pisz Exec=export ... i nie oczekuj, że pulpit zinterpretuje to jako twoją powłokę logowania. Miej też na uwadze zasady cytowania i obsługiwane kody pól wpisu pulpitu; to kolejny parser.

Sprawdź, czy uruchomiono coś nowego

Niektóre aplikacje wysyłają żądanie do już działającej instancji. Niektóre wpisy używają aktywacji D-Bus, która ma własną ścieżkę uruchamiania. Nowe kliknięcie ikony nie tworzy świeżego procesu ze świeżo edytowanym środowiskiem Exec.

Zidentyfikuj instancję wysyłającą żądanie i konfigurację, którą naprawdę posiada. Kontrolowane świeże uruchomienie może zawęzić porównanie, gdy jest to właściwe. Unikaj ponownej instalacji aplikacji, zanim ustalisz, czy zamierzone środowisko w ogóle do niej dotarło.