কে সেই প্রক্সিটা আবার Bash-এ ফিরিয়ে আনে?

যদি পরের টার্মিনালে http_proxy ফিরে আসে, তবে কে এটি দিয়েছে তা খুঁজুন। আরেকটি unset .bashrc এর শেষে একটি লঞ্চের জন্য মানটি লুকাতে পারে, অথচ এর উৎস অন্যত্র সক্রিয় থাকে।

1. ব্যর্থ লঞ্চটি চিহ্নিত করুন। এটি কি একটি ইন্টারঅ্যাকটিভ লগইন shell, একটি নন-লগইন টার্মিনাল, নাকি একটি নন-ইন্টারঅ্যাকটিভ কাজ? sh হিসেবে ডাকা Bash-ও ভিন্ন নিয়ম মেনে চলে।
2. সেই স্টার্টআপ পথ অনুসরণ করুন। একটি ইন্টারঅ্যাকটিভ লগইন shell /etc/profile পড়ে, তারপর ~/.bash_profile, ~/.bash_login ও ~/.profile এর মধ্যে প্রথম পাওয়া user ফাইল পড়ে। একটি ইন্টারঅ্যাকটিভ নন-লগইন shell সাধারণত ~/.bashrc পড়ে। লগইন ফাইল এটিকে স্পষ্টভাবে source করতে পারে। নন-ইন্টারঅ্যাকটিভ Bash-এর জন্য যেখানে প্রযোজ্য BASH_ENV হিসাব করুন।
3. অ্যাসাইনমেন্টটি খুঁজুন। সেই ফাইল এবং তারা যে ফাইলগুলো source করে সেগুলোতে variable-এর নাম ও পুরোনো প্রক্সি hostname খুঁজুন। প্রাসঙ্গিক /etc/profile.d অংশ এবং বড় হাতের পাশাপাশি ছোট হাতের নামও অন্তর্ভুক্ত করুন।
4. স্টার্টআপ যদি এটি অ্যাসাইন না করে থাকে, parent অনুসরণ করুন। shell তার terminal, লগইন সেশন, service manager বা development tool থেকে environment উত্তরাধিকার পায়। দীর্ঘজীবী parent shell ফাইল সম্পাদনার পরও পুরোনো মান ধরে রাখতে পারে।

PAM-ভিত্তিক লগইনের জন্য /etc/environment-ও দেখুন। মালিকানার উৎসটি ঠিক করুন এবং প্রভাবিত স্টার্টআপ পথ আবার চালু করুন, প্রয়োজনে parent কনফিগারেশন সতেজ করুন। অনুসন্ধান স্থানীয় রাখুন: স্টার্টআপ ফাইল ও environment dump-এ ক্রেডেনশিয়াল থাকতে পারে। যাচাই করার ফল হলো অভীষ্ট command যে মানটি উত্তরাধিকার পায়, শেষ যে ফাইলটি এটি unset করতে পেরেছে তা নয়।