Защо прокси настройките работят в терминал, но не в стартер на работния плот

Експортирате прокси в терминал. Стартирана там команда го използва. Щракването върху иконата на работния плот все пак дава друг маршрут. Иконата не е станала дъщерна на този терминал.

Сесията на работния плот стартира приложения чрез собствен механизъм за стартиране. Тези процеси наследяват онази среда, а не всяка по-късна промяна, направена в несвързан шел. Това може да обясни разлика, без да доказва, че пакетът на приложението е дефектен.

Exec е описание на команда, а не шел скрипт

Спецификацията Desktop Entry дефинира изпълним файл и аргументи за Exec. Тя не обещава разгръщане на шел променливи или вградени шел команди.

За външна програма, която чете съответната променлива на средата, умишлено ограничено стартиране може да има този вид:

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

Сменете както крайната точка, така и изпълнимия файл. Това показва входа на стартирането, а не гаранция, че произволно приложение чете тази променлива. Браузър със собствена изрична прокси политика все още може да избере друг източник на конфигурация. За Chrome, запазете неговия прокси аргумент в потребителски стартер.

Не пишете Exec=export ... и не очаквайте работният плот да го тълкува като вашия шел за вход. Дръжте под око и правилата за цитиране и поддържаните полеви кодове на записа на работния плот; те са друг парсер.

Проверете дали е стартирано нещо ново

Някои приложения изпращат заявката към вече работещ екземпляр. Някои записи използват активиране през D-Bus, което има собствен път на стартиране. Ново щракване върху иконата не установява нов процес с новоредактираната Exec среда.

Идентифицирайте екземпляра, който прави заявката, и конфигурацията, която той действително притежава. Контролирано ново стартиране може да стесни сравнението, когато е уместно. Избягвайте преинсталиране на приложението, преди да установите, че предназначената среда изобщо е стигнала до него.