Bash_profile या bashrc में पर्यावरण चर?

36

मुझे यह प्रश्न मिला है [ब्लॉग]: .bashrc और .bash_profile के बीच अंतर बहुत उपयोगी है, लेकिन सबसे अधिक वोट किए गए उत्तर (जिस तरह से बहुत अच्छा है) को देखने के बाद मेरे पास और प्रश्न हैं। सबसे अधिक मतदान के अंत की ओर, सही उत्तर मैं कथन निम्नानुसार देखता हूं:

ध्यान दें कि आप यहां देख सकते हैं और या तो पर्यावरण चर परिभाषाओं को ~ / .bashrc में डालने या हमेशा टर्मिनलों में लॉगिन गोले लॉन्च करने की सिफारिश करते हैं। दोनों बुरे विचार हैं।

यह एक बुरा विचार क्यों है (मैं लड़ने की कोशिश नहीं कर रहा हूं, मैं सिर्फ समझना चाहता हूं)?
अगर मैं एक पर्यावरण चर सेट करना चाहता हूं और इसे PATH में जोड़ देता हूं (उदाहरण के लिए JAVA_HOME) जहां यह निर्यात प्रविष्टि डालने के लिए सबसे अच्छी जगह होगी? में ~ / .bash_profile या ~ / .bashrc ?
यदि प्रश्न संख्या 2 का उत्तर ~ / .bash_profile है , तो मेरे पास दो और प्रश्न हैं:

3.1। आप ~ / .bashrc के तहत क्या डालेंगे ? केवल उपनाम?

3.2। एक गैर-लॉगिन शेल में, मेरा मानना है कि ~ / .bash_profile "उठाया" नहीं जा रहा है। यदि JAVA_HOME प्रविष्टि का निर्यात bash_profile में था, तो क्या मैं javac & java कमांड निष्पादित कर पाऊंगा ? क्या यह उन्हें पाथ पर मिलेगा? क्या यही कारण है कि कुछ पोस्ट और फ़ोरम JAVA_HOME और एक जैसे ~ / .bashrc पर सेट करने का सुझाव देते हैं ?

अग्रिम में धन्यवाद।

— Viriato
स्रोत

26

एक आधुनिक प्रणाली पर यह उन मामलों में चलाने के लिए विशेष रूप से सामान्य नहीं है जहां यह मायने रखता है, लेकिन ऐसा होता है। (विशेष रूप से, यदि आप vimइस तरह के :r !commandया इन-लाइन !<motion>commandफॉर्म में शेल ऑपरेशन का उपयोग करते हैं ।)

आप ~ / .bashrc के तहत क्या डालेंगे? केवल उपनाम?

आप ~/.bashrcउन चीजों को डालते हैं जो स्वचालित रूप से उपधाराओं द्वारा विरासत में नहीं मिलेंगी; इसका मतलब यह है कि उपनाम और फ़ंक्शन, ज्यादातर, हालांकि कभी-कभी आपके पास चर सेटिंग्स होती हैं जो आप शेल के बाहर नहीं दिखना चाहते हैं (यह बहुत दुर्लभ है)। यह तर्क दिया जा सकता है कि उन लोगों को किसी भी तरह निर्यात किया जाना चाहिए, लेकिन विभिन्न प्रयोगात्मक प्रयासों ने उन्हें पर्यावरण के भीतर छिपाने की कोशिश के साथ संगतता के मुद्दों में भाग लिया है और ज्यादातर को छोड़ दिया गया है।

अगर मैं एक पर्यावरण चर सेट करना चाहता हूं और इसे PATH में जोड़ देता हूं (उदाहरण के लिए JAVA_HOME) जहां यह निर्यात प्रविष्टि डालने के लिए सबसे अच्छी जगह होगी? ~ / .bash_profile या ~ / .bashrc में?

आप पर्यावरण सेटिंग रखते हैं ~/.bash_profileताकि उन्हें प्रारंभिक सेटिंग दी जाए। कभी-कभी आप इन्हें ओवरराइड करना चाहेंगे (अक्सर यह जटिल वातावरण जैसे कि मैटलैब या ताल द्वारा किया जाता है); यदि आप पर्यावरण सेटिंग डालते हैं, ~/.bashrcतो उन वातावरणों के भीतर से चलने वाले गोले पर्यावरण के अनुकूलन को खो देंगे, और परिणामस्वरूप परिणाम ठीक से काम नहीं कर सकते हैं। यह तब भी लागू होता है जब आप कई विकास वातावरणों के प्रबंधन के लिए मॉड्यूल , वर्चुअन , आरवीएम आदि जैसे पैकेज का उपयोग करते हैं; अपनी सेटिंग्स को डालने का ~/.bashrcमतलब है कि आप अपने संपादक के भीतर से जो माहौल चाहते हैं उसे नहीं चला सकते हैं, बल्कि इसके बजाय सिस्टम डिफ़ॉल्ट में मजबूर हो जाएगा।

एक गैर-लॉगिन शेल में, मेरा मानना है कि ~ / .bash_profile "उठाया" नहीं जा रहा है।

यह सही है; आप सामान्य रूप से चाहते हैं कि प्रारंभिक शेल एक लॉगिन शेल हो और इसके तहत शुरू किए गए कोई भी शेल लॉगिन शेल न हों । यदि प्रारंभिक शेल एक लॉगिन शेल नहीं है, तो आपके पास एक डिफ़ॉल्ट PATHया विभिन्न अन्य सेटिंग्स (आपके JAVA_HOMEउदाहरण सहित ) नहीं होंगे।

प्रदर्शन प्रबंधकों से लॉन्च किए गए अधिकांश डेस्कटॉप वातावरण (जिसे कहना है, अधिकांश विशाल ग्राफ़िकल लॉगिन) पूरे डेस्कटॉप के लिए एक लॉगिन वातावरण सेट नहीं करते हैं, इसलिए आपको टर्मिनलों में प्रारंभिक शेल को लॉगिन शेल के रूप में चलाने के लिए मजबूर किया जाता है। यह कई समस्याओं का कारण बनता है (विशेष रूप से PATHऔर जैसे कि उदाहरण के लिए चलने वाले कार्यक्रमों के लिए उपलब्ध पैनल ठीक से सेट नहीं है, क्योंकि पैनल टर्मिनल नहीं है और नहीं चला है ~/.bash_profile), लेकिन एक उचित समझौता है जो यह हमेशा संभव नहीं है ~/.bash_profileअपनी सामग्री के आधार पर एक प्रदर्शन प्रबंधक द्वारा शुरू किए गए सत्र की शुरुआत में गैर-संवादात्मक वातावरण में चलाने के लिए। इसमें कभी-कभी पर्यावरण सेटिंग रखने का सुझाव दिया जाता है~/.bashrcइसके बजाय एक लॉगिन शेल को कॉन्फ़िगर करने के बजाय; जैसा कि ऊपर चर्चा की गई है, यह तब तक काम करता है जब तक आपको उस वातावरण को ओवरराइड करने की आवश्यकता नहीं होती है, और ऐसा करने के लिए आपको एक बार अजीब टूटना पड़ता है।

मैंने हाल ही में ओएस एक्स पर इस तरह के एक मुद्दे का निदान करने में मदद की, जहां एक उपयोगकर्ता, जिसने ~/.bashrcतब सेटिंग में रखा था, बाद में उपयोग करना शुरू कर दिया rvmऔर perlbrew ने अजीब व्यवहार देखा, क्योंकि दोनों द्वारा स्थापित वातावरण ~/.bashrcसंपादकों के अंदर "पूर्ववत" थे और sudo(जो ओएस एक्स पर थे) , लिनक्स के विपरीत, उपयोगकर्ता को प्रचारित करता है $HOMEताकि उनके ~/.bashrcरूट शेल द्वारा चलाया जा सके)। उन वातावरणों का उपयोग करने की कोशिश करने से पहले, कोई समस्या नहीं थी; उनका उपयोग शुरू करने पर, वे अपनी सेटिंग्स की अप्रत्याशित हानि से हतप्रभ थे।

— geekosaur
स्रोत

1

मुझे लगता है कि मैं समझता हूं, मुझे इसे और अधिक आंतरिक बनाने के लिए इसे अधिक बार पढ़ना पड़ सकता है लेकिन मैं निम्नलिखित निष्कर्ष निकाल रहा हूं। उद्यम वातावरण में बिना किसी साइड इफेक्ट के कस्टमाइज्ड गोले को नियंत्रित करने के लिए, यह पर्यावरण चर को ~ / .bash_profile में डालने का सबसे अच्छा अभ्यास है । PATH को ठीक से सेट करने के लिए उबंटू या लिनक्स टकसाल जैसे एक व्यक्तिगत वातावरण में, मुझे इसे ~ / .bashrc (या यहां तक कि / etc / प्रोफ़ाइल में ) के तहत सेट करना चाहिए । क्या मैं सही हूँ?

— विरियाटो

यह उद्यम वातावरण के साथ करने की तुलना में कम है कि क्या आप सिर्फ एक उपयोगकर्ता या एक डेवलपर हैं; "डेवलपर" की कुछ भिन्न परिभाषाओं के लिए मतलब और ताल के रूप में सिस्टम टूल जैसे हैं modulesऔर rvmडेवलपर उपकरण हैं। सरल विकास भी उन्हें आवश्यकता नहीं है, लेकिन जब आप रूबी, पर्ल, या अजगर के कई संस्करण के खिलाफ परीक्षण करने की जरूरत है तो आप वास्तव में कुछ की तरह चाहते हैं rvm, perlbrewऔर virtualenvयह सब सीधा रखें (क्रमशः) मदद करने के लिए चारों ओर।

— गीकॉउसोर

2

ईमानदार होने के लिए, गुरु के कहने के बावजूद इन दिनों बहुत कम अंतर है।

इसके पीछे मुद्दा यह है कि आजकल हम एक लॉगिन शेल के बजाय ग्राफिकल रूप से लॉगिन करते हैं। अतीत में, हम यूनिक्स उपयोगकर्ताओं को लॉगिन के तुरंत बाद एक सर्वर पर क्या हो रहा है की एक छोटी रिपोर्ट देखना पसंद करते हैं - फिर हम कमांड लाइन द्वारा एक्स शुरू करेंगे - इन रिपोर्ट को अक्सर उत्पन्न करने के लिए कुछ समय की आवश्यकता होती है (जैसे 10-20 सेकंड)। और फिर जब हम xterm शुरू करते हैं तो हम वही नहीं देखना चाहते हैं। इस प्रकार अंतर।

आजकल मुझे नहीं लगता कि भेद अब कोई महत्वपूर्ण है। मुझे लगता है कि अगर आप bash_profile में bashrc स्रोत करते हैं तो इन दिनों कोई भी आपको दोष नहीं दे सकता है।

ध्यान दें कि यह macos x पर लागू नहीं होता है (प्रत्येक टर्मिनल। शुरू किया गया लॉगिन शेल है)

— bubu
स्रोत

मुझे पूरी तरह से यकीन नहीं है कि मैं पूरी तरह से समझता हूं, लेकिन काम पर जब मैं ssh के माध्यम से लॉग इन करता हूं जो एक लॉगिन शेल है, तो bash_profile और bashrc को खट्टा हो जाता है इसलिए मुझे लगता है कि उदाहरण में यह कोई फर्क नहीं पड़ता। लेकिन अगर मैं ग्राफिक रूप से लॉग इन करता हूं (इसका क्या मतलब है)? मेरे व्यक्तिगत ubuntu में लॉगिन की तरह?

— विरियाटो

यहां @bubu उत्तर से सहमत हैं - कोई भी सेटअप जहां ~/.bash_profileस्रोत नहीं ~/.bashrcहै, बल्कि टूटे पर काम करना और क्रिया करना मुश्किल है। ग्राफिकल टर्मिनल एप्स का मतलब है कि यह सिर्फ स्रोत ~ / .bashrc के लिए सरल है और सभी कॉन्फिगरेशन को वहां रखा है।

— रिचवेल

1

खैर, "ग्राफिकल लॉगिन्स" के बारे में, यह इस बात पर निर्भर करता है कि आप किस * डीएम का उपयोग करते हैं ...

GDM (सूक्ति 3.18) के साथ मेरे पास यह है:

/ Etc / GDM / Xsession

#!/bin/sh   <= *important*

...

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

तो, ~ / .profile / बिन / श का उपयोग करके लॉगिन में खट्टा हो जाता है और बिन / बाश नहीं

दो मामले हैं

/ बिन / श / / बिन / बैश से जुड़ा हुआ है, लेकिन "POSIX / बॉर्न" मोड में चलता है
/ bin / श है / bin / पानी का छींटा (Debian / Ubuntu)। सबसे तेज़ लेकिन कम सुविधाओं के साथ (शेलशॉट सपोर्ट;) )

तो / bin / श प्रोफ़ाइल है ~ / .profile और नहीं ~ / .bash_profile, ~ / .zprofile

इस फ़ाइल का उपयोग "शेल एग्नॉस्टिक" सेटिंग्स के लिए किया जाना चाहिए , जैसे पथ और पर्यावरण चर।

लॉगिन-केवल उपयोगकर्ता इंटरैक्शन के लिए कोई निष्पादन योग्य कार्यक्रम होना चाहिए लेकिन यहां (मेल चेक, भाग्य, आदि ...)

~ /.* आरसी केवल "इंटरैक्टिव" सत्र (उदाहरण के लिए उपनाम ...) के लिए हैं

इंटरेक्टिव लॉगइन गोले के लिए बैश और जेडश में अंतर है

बैश स्रोतों को केवल .bash_profile, जबकि zsh स्रोतों को क्रम में:

~ / .Zprofile
~ / .Zshrc
~ / zlogin (यहां ~ / .zshrc में परिभाषित उपनाम उपलब्ध हैं। "इंटरएक्टिव" + "लॉगिन" खंभे के मामले में)

करने का सही तरीका ~ / .bash_profile यहाँ उत्तर दिया गया था:

.Bashrc और .bash_profile के बीच अंतर

if [ -r ~/.profile ]; then . ~/.profile; fi
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

परीक्षण (और प्रोफाइलिंग) को सक्षम करने के लिए, आप इसका उपयोग कर सकते हैं

~ / .Bash_profile:

#!/bin/bash

# ------------------------------------------------
export _DOT_BASH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

if [ -f ~/.profile ] ; then
    . ~/.profile
fi

case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

# ------------------------------------------------
export _DOT_BASH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

~ / .Zprofile:

#!/bin/zsh

# ------------------------------------------------
export _DOT_ZSH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

if [ -f ~/.profile ] ; then
    . ~/.profile
fi

# no need to source, zsh already handle ~/.zshrc

###case "$-" in *i*) if [ -r ~/.zshrc ]; then . ~/.zshrc; fi;; esac

# ------------------------------------------------
export _DOT_ZSH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

फिर, परीक्षण करने के लिए:

chsh -s /bin/bash

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env


chsh -s /bin/zsh

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env

तो RVM / virtualenv ~ / .profile, IMHO में जाना चाहिए

लेकिन यह काम नहीं करता है , कभी-कभी ...

उदाहरण के लिए, virualenvwrapper केवल तभी काम करता है जब Xsession चल रहा शेल एक "मूल" बैश (BASH_VERSION निर्यात कर रहा है)

यदि आप डैश सिस्टम पर हैं, तो पर्यावरण चर और पथ सेटिंग कार्य करते हैं, लेकिन virualenvwrapper फ़ंक्शन परिभाषा काम नहीं करती है क्योंकि स्क्रिप्ट POSIX अनुरूप नहीं है।

स्क्रिप्ट कोई त्रुटि नहीं देती है लेकिन यह बिना किसी "वर्कऑन" परिभाषा के समाप्त हो जाती है ।

तो आप हाथ में पर्यावरण सेट कर सकते हैं ~ /। लाभ , बस ग्राहक से सही अजगर निष्पादन को सक्षम करने के लिए सीधे 1 से शुरू कर दिया:

export VIRTUAL_ENV="/home/mike/var/virtualenvs/myvirtualenv"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME

https://gist.github.com/datagrok/2199506

https://www.bountysource.com/issues/9061991-setting-up-your-computer-virtualenvwrapper-linux-all

लेकिन virualenvwrapper के लिए आपके पास दो विकल्प हैं:

इसे स्रोत में ~ / .bash_profile या ~ / .zprofile (या ~ / .zlogin) जब टर्मिनल को शेल के रूप में जाना जाता है
स्क्रिप्ट को ~ / .bashrc या ~ / zshrc में शामिल करें

इसका मतलब है कि एक्स क्लाइंट (उदाहरण के लिए एमएसीएस) को टर्मिनल शेल से शुरू किया जाना चाहिए न कि ग्राफिकल वन से!

"मुझे कोई संतुष्टि नहीं मिल सकती ..."

— hute37
स्रोत

एक पूरी तरह से अलग कहानी सिस्टमड के साथ सेवाएं चला रही है। कुछ संभावित विकल्प हैं: एक रैपर स्क्रिप्ट लिखना , पर्यावरण को "सेवा" परिभाषा फ़ाइल में परिभाषित करना , एक "env" फ़ाइल में पर्यावरण को एक माता-पिता के खोल में sourced होना। RVM / virtualenv के साथ चीजें

— मुश्किल