ആ പ്രോക്സിയെ വീണ്ടും Bash-ലേക്ക് ആരാണ് കൊണ്ടുവരുന്നത്?

അടുത്ത ടെർമിനലിൽ http_proxy വീണ്ടും വന്നാൽ, അത് ആരാണ് സെറ്റ് ചെയ്തതെന്ന് കണ്ടെത്തുക. മറ്റൊരു unset .bashrc-ന്റെ അവസാനത്തിൽ ഒരു ലോഞ്ചിനായി മൂല്യം മറയ്ക്കാം, എന്നാൽ അതിന്റെ ഉറവിടം മറ്റൊരിടത്ത് സജീവമായി തുടരും.

1. പരാജയപ്പെടുന്ന ലോഞ്ച് തിരിച്ചറിയുക. ഇത് ഇന്ററാക്ടീവ് ലോഗിൻ shell ആണോ, ലോഗിൻ ഇല്ലാത്ത ടെർമിനലോ, അല്ലെങ്കിൽ ഇന്ററാക്ടീവ് അല്ലാത്ത ജോലിയോ? sh എന്ന് വിളിക്കപ്പെടുന്ന Bash-ഉം വ്യത്യസ്ത നിയമങ്ങൾ പിന്തുടരുന്നു.
2. ആ സ്റ്റാർട്ടപ്പ് പാത പിന്തുടരുക. ഇന്ററാക്ടീവ് ലോഗിൻ shell /etc/profile വായിക്കുന്നു, തുടർന്ന് ~/.bash_profile, ~/.bash_login, ~/.profile എന്നിവയിൽ നിന്ന് ആദ്യം ലഭ്യമായ ഉപയോക്തൃ ഫയൽ വായിക്കുന്നു. ഇന്ററാക്ടീവ് അല്ലാത്ത ലോഗിൻ shell സാധാരണയായി ~/.bashrc വായിക്കുന്നു. ലോഗിൻ ഫയൽ അത് വ്യക്തമായി source ചെയ്യാം. ഇന്ററാക്ടീവ് അല്ലാത്ത Bash-ന്, ബാധകമായിടത്ത് BASH_ENV കണക്കിലെടുക്കുക.
3. അസൈൻമെന്റ് കണ്ടെത്തുക. ആ ഫയലുകളിലും അവ source ചെയ്യുന്ന ഫയലുകളിലും variable-ന്റെ പേരും പഴയ പ്രോക്സി hostname-ഉം തിരയുക. പ്രസക്തമായ /etc/profile.d ഭാഗങ്ങളും വലിയക്ഷരത്തിലും ചെറിയക്ഷരത്തിലും ഉള്ള പേരുകളും ഉൾപ്പെടുത്തുക.
4. സ്റ്റാർട്ടപ്പ് അത് അസൈൻ ചെയ്തിട്ടില്ലെങ്കിൽ, parent-നെ പിന്തുടരുക. shell അതിന്റെ terminal, ലോഗിൻ സെഷൻ, സേവന മാനേജർ അല്ലെങ്കിൽ ഡെവലപ്മെന്റ് ടൂളിൽ നിന്ന് environment പാരമ്പര്യമായി സ്വീകരിക്കുന്നു. ദീർഘകാലം ജീവിക്കുന്ന parent shell ഫയൽ തിരുത്തിയതിനുശേഷവും പഴയ മൂല്യം നിലനിർത്താം.

PAM അടിസ്ഥാനമാക്കിയ ലോഗിനുകൾക്ക്, /etc/environment-ഉം പരിശോധിക്കുക. ഉടമസ്ഥതയുള്ള ഉറവിടം തിരുത്തി ബാധിക്കപ്പെട്ട സ്റ്റാർട്ടപ്പ് പാത വീണ്ടും ആരംഭിക്കുക, ആവശ്യമെങ്കിൽ parent കോൺഫിഗറേഷൻ പുതുക്കുക. തിരയലുകൾ ലോക്കലായി സൂക്ഷിക്കുക: സ്റ്റാർട്ടപ്പ് ഫയലുകളിലും environment dump-കളിലും ക്രെഡൻഷ്യലുകൾ ഉണ്ടാകാം. പരിശോധിക്കേണ്ട ഫലം ഉദ്ദേശിച്ച command പാരമ്പര്യമായി സ്വീകരിക്കുന്ന മൂല്യമാണ്, അത് unset ചെയ്യാൻ കഴിഞ്ഞ അവസാന ഫയലല്ല.