ସେହି ପ୍ରକ୍ସିକୁ ପୁଣି 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 କରିପାରିଥିବା ଫାଇଲ୍ ନୁହେଁ।