Exportați un proxy într-un terminal. O comandă pornită acolo îl folosește. Clicul pe pictograma desktopului oferă totuși o altă rută. Pictograma nu a devenit copil al acelui terminal.

O sesiune desktop pornește aplicațiile prin propriul mecanism de lansare. Acele procese moștenesc acel mediu, nu fiecare modificare ulterioară făcută într-un shell fără legătură. Acest lucru poate explica o diferență fără a dovedi că pachetul aplicației este defect.

Exec este o descriere a comenzii, nu un script de shell

Specificația Desktop Entry definește un executabil și argumente pentru Exec. Nu promite expandarea variabilelor de shell și nici comenzile interne ale shell-ului.

Pentru un program extern care citește variabila de mediu relevantă, o lansare delimitată intenționat poate avea această formă:

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

Înlocuiți atât punctul final, cât și executabilul. Aceasta arată intrarea lansării, nu garanția că o aplicație arbitrară citește acea variabilă. Un browser cu propria politică explicită de proxy poate alege în continuare altă sursă de configurare. Pentru Chrome, salvați argumentul său de proxy într-un lansator de utilizator.

Nu scrieți Exec=export ... și nu vă așteptați ca desktopul să îl interpreteze ca shell-ul dumneavoastră de autentificare. Aveți în vedere și regulile de citare și codurile de câmp acceptate ale intrării de desktop; ele sunt un alt parser.

Verificați dacă a fost lansat ceva nou

Unele aplicații trimit cererea către o instanță deja în execuție. Unele intrări folosesc activarea prin D-Bus, care are propria cale de lansare. Un nou clic pe pictogramă nu stabilește un proces nou cu mediul Exec tocmai editat.

Identificați instanța care face cererea și configurația pe care o deține efectiv. O lansare nouă controlată poate restrânge comparația atunci când este potrivit. Evitați reinstalarea aplicației înainte de a stabili dacă mediul dorit a ajuns vreodată la ea.

Articole similare