Ubuntu का डिफ़ॉल्ट ~ / .profile स्रोत ~ / .bashrc क्यों है?


30

ये ~/.profileमेरे 13.10 के साथ आए स्टॉक की सामग्री हैं (टिप्पणी की गई लाइनें हटा दी गई हैं):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

यह डेबियन से विरासत में मिला है लेकिन कैन्येल ने इसे रखने का फैसला क्यों किया? जहाँ तक मुझे पता है, यह मानक * निक्स तरीका नहीं है और मैंने विभिन्न प्रणालियों को देखा है जहाँ ऐसा नहीं हुआ है, इसलिए मुझे लगता है कि उनके पास एक अच्छा कारण रहा होगा। लॉगिन गोले चलाते समय यह अप्रत्याशित व्यवहार का कारण बन सकता है (जैसे कि उदाहरण के लिए मशीन में sshing) जहां उपयोगकर्ता को खट्टा होने की उम्मीद नहीं होगी ~/.bashrc

एकमात्र लाभ जो मैं सोच सकता हूं, वह उपयोगकर्ता को कई स्टार्टअप फ़ाइलों के साथ भ्रमित नहीं करना है और उन्हें .bashrcअकेले संपादित करने की अनुमति देता है और शेल प्रकार की परवाह किए बिना पढ़ा है। हालाँकि, यह एक संदिग्ध लाभ है क्योंकि यह अक्सर लॉगिन के लिए और इंटरैक्टिव गोले के लिए अलग-अलग सेटिंग्स के लिए उपयोगी होता है और यह आपको ऐसा करने से रोकता है। इसके अलावा, लॉगिन शैल बहुत बार ग्राफ़िकल वातावरण में नहीं चलते हैं और जो उन फ़ाइलों में आपके द्वारा सेट किए गए त्रुटियों और चेतावनियों और समस्याओं (ओह माय!) पर निर्भर कर सकते हैं।

तो उबंटू ऐसा क्यों करता है, मुझे क्या याद आ रहा है?


-n "$BASH_VERSION"बैश के बाहर सच क्यों होगा ?
इलियट फ्रिश

@ ElliottFrisch यह नहीं होगा। मेरा सवाल यह है कि .profileस्रोत क्यों है .bashrc, यह सभी लिनक्स संस्करणों में ऐसा नहीं है और मैं सोच रहा हूं कि इसके पीछे तर्क क्या है।
terdon

ऐसा लगता है कि डेबियन अपस्ट्रीम में लागू किया जाएगा ।
इलियट फ्रिश

@ElliottFrisch हाँ, मुझे लगा कि यह नहीं है और इसे देखा और देखा कि यह मेरी टिप्पणी को संपादित करने के लिए समय था। फिर भी, यह एक SuSe प्रणाली पर मेरे द्वारा उपयोग किए जाने की स्थिति नहीं है (हालांकि यह एक CentOS एक पर है) और विभिन्न प्रणालियों (RHs, Fedoras, पुराने Ubuntus) पर मामला नहीं था जहाँ तक मुझे याद है। तो मैं सोच रहा हूँ क्यों।
terdon

जवाबों:


15

यह डेबियन का एक अपस्ट्रीम निर्णय है। इसके लिए तर्क को इस बहुत अच्छे विकि पोस्ट में समझाया गया है , जिसके निम्नलिखित अंश हैं। कार्यकारी सारांश "यह सुनिश्चित करने के लिए है कि GUI और गैर GUI लॉगिन समान तरीके से काम करते हैं":

एक उदाहरण के रूप में xdm लेते हैं। पियरे एक दिन छुट्टी से वापस आता है और पता चलता है कि उसके सिस्टम प्रशासक ने डेबियन सिस्टम पर एक्सडीएम स्थापित किया है। वह बस ठीक से लॉग इन करता है, और xdm उसकी .xsession फाइल पढ़ता है और फ्लक्सबॉक्स चलाता है। जब तक वह गलत स्थान पर एक त्रुटि संदेश प्राप्त नहीं करता, तब तक सब कुछ ठीक लगता है! चूँकि वह अपने .bash_profile में LANG चर को ओवरराइड करता है, और चूंकि xdm कभी नहीं पढ़ता है। bash_profile, उसका LANG चर अब fr_CA के बजाय en_US पर सेट है।

अब, इस समस्या का भोला समाधान यह है कि "xterm" लॉन्च करने के बजाय, वह "xterm -ls" लॉन्च करने के लिए अपने विंडो मैनेजर को कॉन्फ़िगर कर सकता है। यह ध्वज xterm को बताता है कि सामान्य शेल लॉन्च करने के बजाय, उसे एक लॉगिन शेल लॉन्च करना चाहिए। इस सेटअप के तहत, xterm स्पैन / बिन / बैश करता है, लेकिन यह तर्क वेक्टर में "- / बिन / बैश" (या शायद "-बैश") डालता है, इसलिए बैश एक लॉगिन शेल की तरह कार्य करता है। इसका मतलब है कि हर बार जब वह एक नया xterm खोलता है, तो वह / etc / प्रोफाइल और .bash_profile (अंतर्निहित बैश व्यवहार) पढ़ेगा और फिर .bashrc (क्योंकि .bash_profile ऐसा करने के लिए कहता है)। यह पहली बार में ठीक काम करने के लिए लग सकता है - उसकी डॉट फाइलें भारी नहीं हैं, इसलिए वह देरी की सूचना भी नहीं देता है - लेकिन एक अधिक सूक्ष्म समस्या है। उन्होंने अपने फ्लक्सबॉक्स मेनू से सीधे एक वेब ब्राउज़र भी लॉन्च किया, और वेब ब्राउज़र को फ्लक्सबॉक्स से LANG वेरिएबल विरासत में मिला है, जो अब गलत लोकेल पर सेट है। तो जबकि उसका xterms ठीक हो सकता है, और उसके xterms से लॉन्च किया गया कुछ भी ठीक हो सकता है, उसका वेब ब्राउज़र अभी भी उसे गलत लोकेल में पेज दे रहा है।

तो, इस समस्या का सबसे अच्छा समाधान क्या है? वास्तव में एक सार्वभौमिक नहीं है। एक बेहतर तरीका कुछ इस तरह से देखने के लिए .xsession फ़ाइल को संशोधित करना है:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

इसका कारण यह है कि .xsession स्क्रिप्ट को / etc / प्रोफाइल और .bash_profile में पढ़ने के लिए व्याख्या करने वाला शेल मौजूद है और अगर वह पढ़ने योग्य है, तो xmodmap या xterm चलाने से पहले या विंडो प्रबंधक को "निष्पादित" करें। हालाँकि, इस दृष्टिकोण के लिए एक संभावित खामी है: xdm के तहत, शेल जो पढ़ता है .xsession एक नियंत्रित टर्मिनल के बिना चलता है। यदि या तो / etc / प्रोफाइल या .bash_profile किसी भी कमांड का उपयोग करता है जो टर्मिनल की उपस्थिति को मानता है (जैसे कि "भाग्य" या "स्ट्टी"), तो वे कमांड विफल हो सकते हैं। यह प्राथमिक कारण है कि xdm उन फ़ाइलों को डिफ़ॉल्ट रूप से नहीं पढ़ता है। यदि आप इस दृष्टिकोण का उपयोग करने जा रहे हैं, तो आपको यह सुनिश्चित करना होगा कि आपकी "डॉट फाइल" में से सभी कमांड तब सुरक्षित रहें जब कोई टर्मिनल न हो।


मुझे अभी भी लगता है कि यह एक महान विचार नहीं है। आदर्श यह सुनिश्चित करेगा कि प्रदर्शन प्रबंधक एक वैश्विक प्रोफ़ाइल (चेक) और उपयोगकर्ता शेल को सुरक्षित करेगा । अब मुझे पता है कि मैंने कुछ चर में दोहराए गए रास्ते क्यों
बनाए हैं

2

यह उबंटू का मानक व्यवहार है, ~/.bashrcउपयोगकर्ता-स्तर प्रति-इंटरैक्टिव-शेल स्टार्ट अप फ़ाइल है। जब आप मूल रूप से एक टर्मिनल खोलते हैं तो आप एक गैर-लॉगिन, इंटरैक्टिव शेल शुरू करते हैं जो पढ़ता है ~/.bashrcऔर सामग्री ~/.bashrcप्राप्त होती है और आपके वर्तमान शेल वातावरण में निर्यात की जाती है। यह मौजूदा शेल में अपने सभी उपयोगकर्ता परिभाषित शेल चर और कार्यों को प्राप्त करने में मदद करता है । इसके अलावा आप इस तरह की लाइनें पा सकते हैं

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

वर्तमान शेल वातावरण में उपयोगकर्ता परिभाषित उपनाम प्राप्त करने के लिए ।

यह अच्छा उपयोगकर्ता अनुभव प्रदान करने के लिए भी महत्वपूर्ण है। उदाहरण के लिए प्रॉक्सी क्रेडेंशियल में संग्रहीत कर सकती है .bashrc, जब तक यह टर्मिनल अनुप्रयोगों में से कोई भी स्रोत हो ( अर्थात , ping, wget, curl, lynxआदि) ठीक से काम करेंगे। या आपको टर्मिनल खोलने पर हर बार प्रॉक्सी क्रेडेंशियल प्रदान करना होगा।

इसके अलावा उबंटू के डिफॉल्ट .bashrcमें कई उपयोगकर्ता के अनुकूल उपनाम शामिल हैं ( lsऔर grepकोलोरिज़्ड आउटपुट प्रिंट करने के लिए ), विभिन्न शेल वेरिएबल्स के लिए कई नई परिभाषाएं जो उपयोगकर्ता अनुभव को बढ़ाती हैं।

लेकिन आपके ssh लॉगइन या वर्चुअल कंसोल में लॉगिन करने की स्थिति में , आपको मूल रूप से एक इंटरेक्टिव लॉगिन शेल मिलता है। वहाँ खोल दीक्षा फ़ाइल है ~/.profile। इसलिए जब तक आप स्रोत नहीं करते तब तक आप ~/.bashrcउन सभी उपयोगी सेटिंग्स को याद नहीं करते हैं .bashrc। यही कारण है कि उबंटू का डिफ़ॉल्ट है~/.profile स्रोत~/.bashrc

बचने का मामला

  • जिस समय से खटास आ रही हो उसी समय आपको कभी भी ~/.profileअंदर का स्रोत नहीं बनाना चाहिए । यह एक अनंत लूप की स्थिति पैदा करेगा और परिणामस्वरूप आपके टर्मिनल प्रॉम्प्ट को तब तक सस्पेंड किया जाएगा जब तक कि आप हिट नहीं + । ऐसी स्थिति में यदि आप अपने में एक लाइन डालते हैं~/.bashrc~/.bashrc~/.profileCtrlC~/.bashrc
सेट -x

तब आप देख सकते हैं कि टर्मिनल खोलने पर फाइल डिस्क्रिप्टर बंद हो रहा है।


धन्यवाद, यह सभी सही और उपयोगी जानकारी है। यह सिर्फ मेरे सवाल का जवाब नहीं है। मैं लॉगिन और गैर-लॉगिन गोले के बीच के अंतर से परिचित हूं। मेरा सवाल है, उबंटू सिस्टम पर, .profileसोर्सिंग .bashrcक्यों है? SuSe एंटरप्राइज 10 ऐसा नहीं करता है, न ही फेडोरा संस्करणों में से कोई भी मैंने उपयोग किया है लेकिन वह वर्षों पहले था, मैं गलत हो सकता हूं। सेंटोस 5.8 विचित्र रूप से पर्याप्त है। वैसे भी, आप मेरी बात देखते हैं? यह एक डिजाइन विकल्प है और मैं सोच रहा हूं कि यह क्यों बनाया गया था।
terdon

मैंने आपके द्वारा नामित अन्य लिनक्स वितरणों का कठोरता से उपयोग नहीं किया है। क्या आप मुझे बता सकते हैं कि वे ssh सत्र में अलियासेड कमांड जैसी स्थितियों को कैसे संभालते हैं .bashrcया उनमें परिभाषित होते हैं .bash_aliases। उदाहरण के लिए, मेरे पास एक उर्फ ​​के lsरूप ls --color=autoमें मेरे लिए .bashrcऔर मेरे .bashrcपास मेरे से खट्टा हो गया .profile। यहाँ मैं ssh से भी उपनाम का उपयोग कर सकता हूँ। या मैं ssh सत्र में प्रॉक्सी का उपयोग कर सकता हूं। मैं अपने स्रोत नहीं है, तो .bashrcसे .profileमैं उन सुविधाओं ढीला। मुझे लगता है कि यह सब बेहतर उपयोगकर्ता अनुभव के बारे में है।
3

वे नहीं करते हैं, उन उपनाम काम नहीं करेगा। और हाँ, सोर्सिंग .bashrcठीक करता है। लेकिन यह भी समस्याओं का कारण बनता है, मुझे याद है कि मैंने पहली बार एक ऐसी प्रणाली का उपयोग किया था जिसमें यह व्यवहार था जो मुझे ये अजीब संदेश मिलते थे जब sshइसका कारण यह था कि मैं xset b offअपने उपयोग में था .bashrcजो टर्मिनल घंटी को अक्षम करता था लेकिन केवल एक एक्स प्रणाली में तो यह त्रुटि संदेश दे रहा था। मुझे यह समझने के लिए उम्र लग गई कि क्या चल रहा था क्योंकि मुझे नहीं लगता था कि .bashrcलॉगिन शेल चलाते समय पढ़ा जाएगा। मैं सोच रहा हूँ कि क्या इस बारे में "आधिकारिक" बयान है।
terdon

मैं आपसे सहमत हुँ। मुझे पहले भी कुछ परेशानी का सामना करना पड़ा । लेकिन यह ज्यादातर उपयोगी और उपयोगकर्ता के अनुकूल है, अगर आप ध्यान रखें और कुछ विशेष मामलों से बचें। है ना :)
souravc

हाँ, इसके वैध कारण हैं। मैं बस इस बात के लिए उत्सुक था कि क्या कैनोनिकल ने कभी इस अपस्ट्रीम फैसले को रखने के लिए अपना औचित्य दिया था।
terdon
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.