टर्मिनलमा प्रोक्सी सेटिङहरू काम किन गर्छन् तर डेस्कटप लन्चरमा गर्दैनन्
प्रोक्सी कन्फिगरेसनलाई डेस्कटपको वास्तविक लन्च सीमामा राख्नुहोस् र शेल सुरुवातका अनुमानहरूको सट्टा डेस्कटप प्रविष्टिको कमाण्ड ढाँचा प्रयोग गर्नुहोस्।
तपाईं टर्मिनलमा प्रोक्सी एक्सपोर्ट गर्नुहुन्छ। त्यहाँ सुरु गरिएको कमाण्डले त्यसलाई प्रयोग गर्छ। डेस्कटप आइकनमा क्लिक गर्दा अझै अर्को मार्ग दिन्छ। आइकन त्यो टर्मिनलको सन्तान बनेन।
डेस्कटप सत्रले आफ्नै लन्च मेसिनरीमार्फत अनुप्रयोगहरू सुरु गर्छ। ती प्रक्रियाहरूले त्यो वातावरण वंशानुगत रूपमा पाउँछन्, असम्बन्धित शेलभित्र पछि गरिएको हरेक सम्पादन होइन। यसले भिन्नता व्याख्या गर्न सक्छ, तर अनुप्रयोग प्याकेज त्रुटिपूर्ण छ भनी प्रमाणित गर्दैन।
Exec कमाण्डको विवरण हो, शेल स्क्रिप्ट होइन
Desktop Entry विनिर्देशले Exec का लागि कार्यान्वयनयोग्य फाइल र आर्गुमेन्ट परिभाषित गर्छ। यसले शेल चरको विस्तार वा शेल बिल्टइनको वाचा गर्दैन।
सम्बन्धित वातावरण चर पढ्ने बाह्य प्रोग्रामका लागि, जानाजान सीमित लन्चको यो रूप हुन सक्छ:
Exec=env https_proxy=http://proxy.example:8080 /path/to/applicationएन्डपोइन्ट र कार्यान्वयनयोग्य फाइल दुवै बदल्नुहोस्। यसले लन्च इनपुट देखाउँछ, कुनै पनि अनुप्रयोगले त्यो चर पढ्छ भन्ने ग्यारेन्टी होइन। आफ्नै स्पष्ट प्रोक्सी नीति भएको ब्राउजरले अझै अर्को कन्फिगरेसन स्रोत छान्न सक्छ। Chrome का लागि, यसको प्रोक्सी आर्गुमेन्ट प्रयोगकर्ता लन्चरमा सुरक्षित गर्नुहोस्।
Exec=export ... लेखेर डेस्कटपले यसलाई तपाईंको लगइन शेलका रूपमा व्याख्या गर्छ भनी नसोच्नुहोस्। डेस्कटप प्रविष्टिका उद्धरण नियम र समर्थित फिल्ड कोड पनि ध्यानमा राख्नुहोस्; ती अर्को पार्सर हुन्।
केही नयाँ लन्च भयो कि जाँच्नुहोस्
केही अनुप्रयोगहरूले अनुरोध पहिले नै चलिरहेको इन्स्ट्यान्समा पठाउँछन्। केही प्रविष्टिहरूले आफ्नै लन्च मार्ग भएको D-Bus सक्रियता प्रयोग गर्छन्। नयाँ आइकन क्लिकले भर्खरै सम्पादित Exec वातावरणसहित नयाँ प्रक्रिया स्थापित गर्दैन।
अनुरोध गर्ने इन्स्ट्यान्स र यसले साँच्चै स्वामित्व लिएको कन्फिगरेसन पहिचान गर्नुहोस्। उपयुक्त हुँदा नियन्त्रित नयाँ लन्चले तुलना साँघुरो बनाउन सक्छ। अभीष्ट वातावरण कहिल्यै यससम्म पुग्यो कि भनी स्थापित गर्नुअघि अनुप्रयोग पुनः स्थापना गर्नबाट बच्नुहोस्।