কেন প্রক্সি সেটিংস টার্মিনালে কাজ করে কিন্তু ডেস্কটপ লঞ্চারে করে না
প্রক্সি কনফিগারেশন ডেস্কটপ লঞ্চের প্রকৃত সীমানায় রাখুন এবং শেল শুরুর অনুমানের বদলে ডেস্কটপ এন্ট্রির কমান্ড ফরম্যাট ব্যবহার করুন।
আপনি টার্মিনালে একটি প্রক্সি এক্সপোর্ট করেন। সেখানে শুরু করা একটি কমান্ড সেটি ব্যবহার করে। ডেস্কটপ আইকনে ক্লিক করলে তবুও অন্য পথ পাওয়া যায়। আইকনটি ওই টার্মিনালের সন্তান হয়নি।
একটি ডেস্কটপ সেশন নিজের লঞ্চ মেশিনারির মাধ্যমে অ্যাপ্লিকেশন শুরু করে। সেই প্রক্রিয়াগুলো ওই পরিবেশ উত্তরাধিকারসূত্রে পায়, কোনও সম্পর্কহীন শেলের ভেতরে পরে করা প্রতিটি সম্পাদনা নয়। এটি একটি পার্থক্য ব্যাখ্যা করতে পারে, কিন্তু অ্যাপ্লিকেশন প্যাকেজটি ত্রুটিপূর্ণ বলে প্রমাণ করে না।
Exec হল কমান্ডের বিবরণ, শেল স্ক্রিপ্ট নয়
Desktop Entry স্পেসিফিকেশন Exec এর জন্য একটি এক্সিকিউটেবল ও আর্গুমেন্ট সংজ্ঞায়িত করে। এটি শেল ভেরিয়েবল সম্প্রসারণ বা শেল বিল্টইনের প্রতিশ্রুতি দেয় না।
সংশ্লিষ্ট পরিবেশ ভেরিয়েবল পড়ে এমন একটি বাহ্যিক প্রোগ্রামের জন্য, ইচ্ছাকৃতভাবে সীমিত লঞ্চের এই রূপ হতে পারে:
Exec=env https_proxy=http://proxy.example:8080 /path/to/applicationএন্ডপয়েন্ট ও এক্সিকিউটেবল দুটোই বদলান। এটি লঞ্চ ইনপুট দেখায়, কোনও নির্বিচার অ্যাপ্লিকেশন ওই ভেরিয়েবল পড়বে এমন নিশ্চয়তা নয়। নিজস্ব স্পষ্ট প্রক্সি নীতি থাকা একটি ব্রাউজার তবুও অন্য কনফিগারেশন উৎস বেছে নিতে পারে। Chrome এর জন্য, এর প্রক্সি আর্গুমেন্ট একটি ব্যবহারকারী লঞ্চারে সংরক্ষণ করুন।
Exec=export ... লিখবেন না এবং ডেস্কটপ এটি আপনার লগইন শেল হিসেবে ব্যাখ্যা করবে বলে আশা করবেন না। ডেস্কটপ এন্ট্রির উদ্ধৃতি নিয়ম ও সমর্থিত ফিল্ড কোডও নজরে রাখুন; সেগুলো আরেকটি পার্সার।
নতুন কিছু লঞ্চ হয়েছে কি না পরীক্ষা করুন
কিছু অ্যাপ্লিকেশন অনুরোধ ইতিমধ্যে চলমান একটি ইনস্ট্যান্সে পাঠায়। কিছু এন্ট্রি D-Bus অ্যাক্টিভেশন ব্যবহার করে, যার নিজস্ব লঞ্চ পথ আছে। নতুন আইকন ক্লিক নতুনভাবে সম্পাদিত Exec পরিবেশসহ নতুন প্রক্রিয়া তৈরি করে না।
অনুরোধকারী ইনস্ট্যান্সটি এবং এটি প্রকৃতপক্ষে যে কনফিগারেশনের মালিক তা চিহ্নিত করুন। উপযুক্ত হলে নিয়ন্ত্রিত নতুন লঞ্চ তুলনাটি সংকুচিত করতে পারে। অভীষ্ট পরিবেশ কখনও এতে পৌঁছেছে কি না তা নিশ্চিত করার আগে অ্যাপ্লিকেশনটি পুনরায় ইনস্টল করা এড়িয়ে চলুন।