Зашто прокси поставке раде у терминалу али не у покретачу радне површине

Извезете прокси у терминалу. Наредба покренута тамо га користи. Клик на икону радне површине ипак даје другу путању. Икона није постала дете тог терминала.

Сесија радне површине покреће апликације кроз сопствени механизам покретања. Ти процеси наслеђују то окружење, а не сваку каснију измену направљену у неповезаној љусци. То може објаснити разлику, али не доказује да је пакет апликације неисправан.

Exec је опис наредбе, а не скрипта љуске

Спецификација Desktop Entry дефинише извршну датотеку и аргументе за Exec. Не обећава проширење променљивих љуске ни уграђене наредбе љуске.

За спољни програм који чита одговарајућу променљиву окружења, намерно ограничено покретање може имати овај облик:

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

Замените и крајњу тачку и извршну датотеку. То показује улаз покретања, а не гаранцију да ће произвољна апликација читати ту променљиву. Прегледач са сопственом изричитом прокси политиком ипак може изабрати други извор конфигурације. За Chrome, сачувајте његов прокси аргумент у корисничком покретачу.

Не пишите Exec=export ... и не очекујте да ће радна површина то протумачити као вашу пријавну љуску. Имајте на уму и правила цитирања те подржане кодове поља уноса радне површине; они су још један парсер.

Проверите да ли је покренуто нешто ново

Неке апликације шаљу захтев већ покренутој инстанци. Неки уноси користе D-Bus активацију, која има сопствену путању покретања. Нови клик на икону не успоставља свеж процес са тек уређеним Exec окружењем.

Утврдите инстанцу која шаље захтев и конфигурацију коју она заиста поседује. Контролисано свеже покретање може сузити поређење када је то прикладно. Избегавајте поновну инсталацију апликације пре него што утврдите да ли је намеравано окружење икада дошло до ње.