टर्मिनल में प्रॉक्सी सेटिंग्स क्यों काम करती हैं पर डेस्कटॉप लॉन्चर में नहीं

आप टर्मिनल में प्रॉक्सी एक्सपोर्ट करते हैं। वहाँ शुरू किया गया कमांड उसका उपयोग करता है। डेस्कटॉप आइकन पर क्लिक करने से फिर भी दूसरा रास्ता मिलता है। आइकन उस टर्मिनल की संतान नहीं बना।

डेस्कटॉप सत्र अपनी लॉन्च मशीनरी से एप्लिकेशन शुरू करता है। वे प्रक्रियाएँ वही वातावरण विरासत में पाती हैं, किसी असंबंधित शेल के भीतर बाद में किया गया हर संपादन नहीं। यह किसी अंतर को समझा सकता है, पर यह सिद्ध नहीं करता कि एप्लिकेशन पैकेज ख़राब है।

Exec एक कमांड विवरण है, शेल स्क्रिप्ट नहीं

Desktop Entry विनिर्देश Exec के लिए एक निष्पादन-योग्य फ़ाइल और आर्ग्युमेंट परिभाषित करता है। यह शेल चरों के विस्तार या शेल बिल्टइन का वादा नहीं करता।

किसी बाहरी प्रोग्राम के लिए जो संबंधित वातावरण चर पढ़ता है, जान-बूझकर सीमित लॉन्च इस रूप में हो सकता है:

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

एंडपॉइंट और निष्पादन-योग्य फ़ाइल, दोनों बदलें। यह लॉन्च इनपुट दिखाता है, यह गारंटी नहीं कि कोई भी एप्लिकेशन वह चर पढ़ेगा। अपनी स्पष्ट प्रॉक्सी नीति वाला ब्राउज़र फिर भी कोई दूसरा कॉन्फ़िगरेशन स्रोत चुन सकता है। Chrome के लिए, उसका प्रॉक्सी आर्ग्युमेंट किसी उपयोगकर्ता लॉन्चर में सहेजें।

Exec=export ... मत लिखिए और यह उम्मीद मत कीजिए कि डेस्कटॉप इसे आपके लॉगिन शेल के रूप में समझेगा। डेस्कटॉप एंट्री के उद्धरण नियम और समर्थित फ़ील्ड कोड भी ध्यान में रखें; वे एक और पार्सर हैं।

जाँचें कि कुछ नया लॉन्च हुआ या नहीं

कुछ एप्लिकेशन अनुरोध पहले से चल रहे इंस्टेंस को भेजते हैं। कुछ एंट्रियाँ D-Bus सक्रियण का उपयोग करती हैं, जिसका अपना लॉन्च पथ है। नया आइकन क्लिक नए संपादित Exec वातावरण के साथ नई प्रक्रिया स्थापित नहीं करता।

अनुरोध करने वाले इंस्टेंस और उसके वास्तव में स्वामित्व वाले कॉन्फ़िगरेशन की पहचान करें। उपयुक्त होने पर नियंत्रित नया लॉन्च तुलना को सँकरा कर सकता है। इच्छित वातावरण कभी उस तक पहुँचा या नहीं, यह स्थापित करने से पहले एप्लिकेशन को फिर से इंस्टॉल करने से बचें।