Чому налаштування проксі працюють у терміналі, але не в стартері робочого столу

Ви експортуєте проксі в терміналі. Команда, запущена там, використовує його. Клацання значка робочого столу все одно дає інший маршрут. Значок не став дочірнім процесом цього термінала.

Сеанс робочого столу запускає програми через власний механізм запуску. Ці процеси успадковують те середовище, а не кожну пізнішу зміну, зроблену в не пов'язаній оболонці. Це може пояснити різницю, не доводячи, що пакет програми дефектний.

Exec — це опис команди, а не скрипт оболонки

Специфікація Desktop Entry визначає виконуваний файл і аргументи для Exec. Вона не обіцяє розкриття змінних оболонки чи вбудованих команд оболонки.

Для зовнішньої програми, яка читає відповідну змінну середовища, навмисно обмежений запуск може мати такий вигляд:

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

Замініть і кінцеву точку, і виконуваний файл. Це демонструє вхідні дані запуску, а не гарантію, що довільна програма прочитає цю змінну. Браузер із власною явною політикою проксі все одно може вибрати інше джерело конфігурації. Для Chrome збережіть його аргумент проксі в користувацькому стартері.

Не пишіть Exec=export ... і не очікуйте, що робочий стіл витлумачить це як вашу оболонку входу. Майте також на увазі правила цитування та підтримувані коди полів запису робочого столу; це ще один аналізатор.

Перевірте, чи було запущено щось нове

Деякі програми надсилають запит уже запущеному екземпляру. Деякі записи використовують активацію через D-Bus, яка має власний шлях запуску. Нове клацання значка не створює свіжий процес із щойно зміненим середовищем Exec.

Визначте екземпляр, що надсилає запит, і конфігурацію, якою він насправді володіє. Контрольований свіжий запуск може звузити порівняння, коли це доречно. Уникайте перевстановлення програми, доки не встановите, чи взагалі досягло її передбачене середовище.