કોણ તે પ્રોક્સીને ફરીથી 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 માં credentials હોઈ શકે છે. ચકાસવાનું પરિણામ એ છે કે ઇચ્છિત command જે મૂલ્ય વારસામાં લે છે, એ છેલ્લી ફાઇલ નહીં જે તેને unset કરી શકી.