چه کسی آن پروکسی را دوباره در Bash برمی‌گرداند؟

اگر http_proxy در ترمینال بعدی برگشت، ببینید چه کسی آن را تنظیم کرده است. یک unset دیگر در انتهای .bashrc می‌تواند مقدار را برای یک اجرا پنهان کند در حالی که منبع آن جای دیگری فعال می‌ماند.

1. اجرای ناموفق را مشخص کنید. آیا پوسته ورود تعاملی است، ترمینالی بدون ورود، یا کاری غیرتعاملی؟ Bash وقتی به‌عنوان sh فراخوانی شود نیز قواعد متفاوتی دارد.
2. آن مسیر راه‌اندازی را دنبال کنید. پوسته ورود تعاملی /etc/profile را می‌خواند و سپس نخستین فایل کاربری موجود از میان ~/.bash_profile، ~/.bash_login و ~/.profile را. پوسته تعاملی بدون ورود معمولاً ~/.bashrc را می‌خواند. یک فایل ورود می‌تواند آن را صریحاً source کند. برای Bash غیرتعاملی، BASH_ENV را در جایی که کاربرد دارد در نظر بگیرید.
3. تخصیص را پیدا کنید. در آن فایل‌ها و فایل‌هایی که source می‌کنند، نام متغیر و نام میزبان قدیمی پروکسی را جست‌وجو کنید. قطعه‌های مرتبط /etc/profile.d و نام‌ها را با حروف بزرگ و همچنین کوچک بگنجانید.
4. اگر راه‌اندازی آن را تخصیص نداده، والد را ردیابی کنید. پوسته محیط را از ترمینال، نشست ورود، مدیر سرویس یا ابزار توسعه به ارث می‌برد. یک والد دیرزیست می‌تواند پس از ویرایش یک فایل پوسته، مقدار قدیمی را نگه دارد.

برای ورودهای مبتنی بر PAM، /etc/environment را هم بررسی کنید. منبع مالک را اصلاح کنید و مسیر راه‌اندازی متأثر را دوباره اجرا کنید و در صورت نیاز پیکربندی والد را تازه کنید. جست‌وجوها را محلی نگه دارید: فایل‌های راه‌اندازی و خروجی‌های محیط می‌توانند اعتبارنامه داشته باشند. نتیجه‌ای که باید بررسی شود مقداری است که فرمان موردنظر به ارث می‌برد، نه آخرین فایلی که توانست آن را unset کند.