چرا تنظیمات پروکسی در ترمینال کار می‌کند اما در راه‌انداز میزکار نه
پیکربندی پروکسی را در مرز واقعی راه‌اندازی میزکار قرار دهید و به‌جای فرض‌های مربوط به آغاز پوسته، از قالب فرمان ورودی میزکار استفاده کنید.
در ترمینال یک پروکسی صادر می‌کنید. فرمانی که همان‌جا آغاز شود از آن استفاده می‌کند. کلیک روی نماد میزکار همچنان مسیر دیگری می‌دهد. نماد فرزند آن ترمینال نشد.
نشست میزکار برنامه‌ها را با سازوکار راه‌اندازی خودش آغاز می‌کند. آن فرایندها آن محیط را به ارث می‌برند، نه هر ویرایش بعدی را که در پوسته‌ای بی‌ربط انجام شده باشد. این می‌تواند تفاوتی را توضیح دهد بدون آنکه ثابت کند بستهٔ برنامه معیوب است.
Exec توصیف یک فرمان است، نه اسکریپت پوسته
مشخصهٔ Desktop Entry یک فایل اجرایی و آرگومان‌ها را برای Exec تعریف می‌کند. اما گسترش متغیرهای پوسته یا فرمان‌های درونی پوسته را وعده نمی‌دهد.
برای برنامه‌ای بیرونی که متغیر محیطی مربوط را می‌خواند، یک راه‌اندازی عامدانه محدود می‌تواند این شکل را داشته باشد:
Exec=env https_proxy=http://proxy.example:8080 /path/to/applicationهم نقطهٔ پایانی و هم فایل اجرایی را جایگزین کنید. این ورودی راه‌اندازی را نشان می‌دهد، نه تضمینی بر اینکه برنامه‌ای دلخواه آن متغیر را بخواند. مرورگری با سیاست پروکسی صریح خودش همچنان می‌تواند منبع پیکربندی دیگری برگزیند. برای Chrome، آرگومان پروکسی آن را در یک راه‌انداز کاربری ذخیره کنید.
Exec=export ... را ننویسید و انتظار نداشته باشید میزکار آن را پوستهٔ ورود شما تفسیر کند. قواعد نقل‌قول و کدهای فیلد پشتیبانی‌شدهٔ ورودی میزکار را نیز در نظر بگیرید؛ آن‌ها تجزیه‌کنندهٔ دیگری هستند.
بررسی کنید که آیا چیز تازه‌ای راه‌اندازی شده است
برخی برنامه‌ها درخواست را به نمونه‌ای که از پیش در حال اجراست می‌فرستند. برخی ورودی‌ها از فعال‌سازی D-Bus استفاده می‌کنند که مسیر راه‌اندازی خودش را دارد. کلیک تازه روی نماد، فرایند تازه‌ای با محیط Exec تازه‌ویرایش‌شده ایجاد نمی‌کند.
نمونه‌ای را که درخواست می‌فرستد و پیکربندی‌ای را که واقعاً در اختیار دارد مشخص کنید. یک راه‌اندازی تازهٔ کنترل‌شده می‌تواند در صورت لزوم مقایسه را محدودتر کند. پیش از آنکه روشن کنید محیط موردنظر هرگز به آن رسیده است یا نه، از نصب دوبارهٔ برنامه بپرهیزید.