Bash_profile veya bashrc'deki ortam değişkenleri?
Bu soruyu [blog] buldum: .bashrc ve .bash_profile arasındaki fark çok faydalı ama en çok oylanan yanıtı gördükten sonra (bu arada çok iyi) başka sorularım var. En çok oylanan doğru cevabın sonuna doğru ifadeyi şu şekilde görüyorum:
Ortam değişkeni tanımlarını ~ / .bashrc içine koymak veya her zaman terminallerde oturum açma kabuklarını başlatmak için burada ve orada öneriler görebileceğinizi unutmayın. İkisi de kötü fikirler.
Neden kötü bir fikir (kavga etmeye çalışmıyorum, sadece anlamak istiyorum)?
Bir ortam değişkeni ayarlamak ve onu dışa aktarma girişini koymak için en iyi yer olan YOL'a (örneğin JAVA_HOME) eklemek istersem? içinde ~ / .bash_profile veya ~ / .bashrc ?
2. sorunun cevabı ~ / .bash_profile ise , o zaman iki sorum daha var:
3.1. ~ / .Bashrc altına ne koyardınız ? sadece takma adlar?
3.2. Giriş yapılmayan bir kabukta ~ / .bash_profile dosyasının "alınmadığını" düşünüyorum. JAVA_HOME girişinin dışa aktarımı bash_profile içinde olsaydı, javac & java komutlarını çalıştırabilir miyim? Onları PATH üzerinde bulur mu? Bazı yayınların ve forumların JAVA_HOME ve benzerlerinin ~ / .bashrc olarak ayarlanmasını önermesinin nedeni bu mu?
Şimdiden teşekkürler.
Yanıtlar
Modern bir sistemde, önemli olan durumlara rastlamak özellikle yaygın değildir, ama olur. (Özellikle, shell işlemlerini kullanır ise vimgibi :r !commandya da in-line !<motion>commandformu).
~ / .Bashrc altına ne koyardınız? sadece takma adlar?
~/.bashrcAlt kabuklar tarafından otomatik olarak miras alınmayacak şeyleri koyarsınız ; bu, çoğunlukla, bazen kabuk dışında görünmesini istemediğiniz değişken ayarlara sahip olmanıza rağmen (bu çok nadirdir) takma adlar ve işlevler anlamına gelir. Bunların bir şekilde ihraç edilmesi gerektiği iddia edilebilir, ancak çeşitli deneysel girişimler, onları ortamda saklamaya çalışmakla uyumluluk sorunlarıyla karşılaşmış ve çoğunlukla terk edilmiştir.
Bir ortam değişkeni ayarlamak ve onu dışa aktarma girişini koymak için en iyi yer olan YOL'a (örneğin JAVA_HOME) eklemek istersem? ~ / .bash_profile veya ~ / .bashrc içinde?
Ortam ayarlarını ~/.bash_profile, onlara mantıklı başlangıç ayarları verilecek şekilde koyarsınız . Bazen bunları geçersiz kılmak isteyebilirsiniz (bu genellikle Matlab veya Cadence gibi karmaşık ortamlar tarafından yapılır); Ortam ayarlarını yerleştirirseniz, ~/.bashrcbu ortamların içinden çalıştırılan kabuklar ortamların özelleştirmelerini kaybedecek ve sonuç olarak işler düzgün çalışmayabilir. Bu , birden çok geliştirme ortamını yönetmek için modüller , virtualenv , rvm , vb. Gibi bir paket kullanıyorsanız da geçerlidir ; ayarlarınızı koymak, ~/.bashrcistediğiniz ortamı düzenleyicinizin içinden çalıştıramayacağınız, bunun yerine sistem varsayılanına zorlanacağınız anlamına gelir.
Giriş yapılmayan bir kabukta ~ / .bash_profile dosyasının "alınmadığını" düşünüyorum.
Doğru; normalde ilk kabuğun bir giriş kabuğu olmasını ve bu kabuk altında başlayan herhangi bir kabuğun oturum açma kabukları olmamasını istersiniz . İlk kabuk bir giriş kabuğu değilse, varsayılan PATHveya çeşitli başka ayarlara ( JAVA_HOMEörneğiniz dahil ) sahip olmayacaksınız .
Görüntü yöneticilerinden başlatılan çoğu masaüstü ortamı (yani, grafiksel oturum açma işlemlerinin büyük çoğunluğu) tüm masaüstü için bir oturum açma ortamı oluşturmaz, bu nedenle terminallerdeki ilk kabuğu bir oturum kabuğu olarak çalıştırmaya zorlanırsınız. Bu, bir dizi soruna neden olur (özellikle PATHpanellerden çalıştırılan programlar için mevcut olan ve benzerlerinin düzgün kurulmaması, çünkü panel bir terminal değildir ve çalışmamıştır ~/.bash_profile), ancak her zaman mümkün olmadığı göz önüne alındığında makul bir uzlaşmadır. ~/.bash_profileiçeriğine bağlı olarak bir görüntü yöneticisi tarafından başlatılan bir oturumun başında etkileşimli olmayan ortamda sağlıklı bir şekilde çalıştırmak . Bazen ~/.bashrcbunun yerine bir oturum açma kabuğu yapılandırmak yerine ortam ayarlarının yerleştirilmesi önerilir ; yukarıda tartışıldığı gibi, bu ortamı geçersiz kılmanız gerekmediği sürece işe yarar ve bunu yapmanız gerektiğinde tuhaf kırılmalara neden olur .
Geçenlerde OS X üzerinde böyle bir sorunu teşhis verilmesinde yardımcı ayarları koymuştu bir kullanıcı ~/.bashrcdaha sonra kullanmaya başladı rvmve perlbrew ortamları iki tarafından "çözülmüş" olduklarını tarafından kurulmuş, çünkü testere garip davranışlar ~/.bashrciçine editörler ve sudo(OS X üzerinde hangi , Linux'tan farklı olarak, kullanıcınınkini kök kabuk tarafından çalıştırılacak $HOMEşekilde yayar ~/.bashrc). Bu ortamları kullanmaya başlamadan önce hiçbir sorun yoktu; onları kullanmaya başladıklarında, ayarlarının beklenmedik şekilde kaybolması karşısında şaşkına döndüler.
dürüst olmak gerekirse, bu günlerde gurunun söylediklerine rağmen çok az fark var.
bunun arkasındaki sorun, günümüzde bir giriş kabuğu yerine grafiksel olarak giriş yapmamızdır. geçmişte, unix kullanıcıları, oturum açtıktan hemen sonra bir sunucuda neler olup bittiğine dair kısa bir rapor görmeyi severiz - o zaman X'i komut satırından başlatırız - bu raporun oluşturulması genellikle biraz zaman alır (örneğin 10-20 saniye). ve sonra örneğin xterm'e başladığımızda aynı şeyi görmek istemiyoruz. böylece fark.
bugünlerde ayrımın artık önemli olduğunu düşünmüyorum. bence bu günlerde bashrc'yi bash_profile'da kaynak yaparsanız kimse sizi suçlayamaz.
bunun macos x için geçerli olmadığını unutmayın (başlatılan her terminal.app bir oturum açma kabuğudur)
"Grafiksel Girişler" hakkında, kullandığınız * DM'ye bağlıdır ...
GDM (Gnome 3.18) ile şuna sahibim:
/ 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"
Dolayısıyla, ~ / .profile , / bin / sh kullanılarak ve / bin / bash kullanılarak oturum açıldığında kaynaklanır.
İki durum var
- / bin / sh , / bin / bash ile bağlantılı ancak "POSIX / Bourne" modunda çalışıyor
- / bin / sh , / bin / dash'dir (debian / ubuntu). En hızlı ancak daha az özellikli (ShellShock desteği;) )
Dolayısıyla / bin / sh profili ~ / .profile olur ve ~ / .bash_profile değil ~ / .zprofile
Bu dosya , yol ve ortam değişkenleri gibi "kabuktan bağımsız" ayarlar için kullanılmalıdır .
Yalnızca oturum açma kullanıcı etkileşimi için yürütülebilir program YOK burada olmalıdır (posta kontrolü, servet vb.)
~ /.* rc yalnızca "etkileşimli" oturumlar içindir (örneğin takma adlar ...)
Etkileşimli oturum açma kabukları için bash ve zsh arasında bir fark vardır
bash yalnızca .bash_profile kaynakları, sırayla zsh kaynakları:
- ~ / .zprofile
- ~ / .zshrc
- ~ / zlogin (burada ~ / .zshrc içinde tanımlanan takma adlar mevcuttur. "etkileşimli" + "oturum açma" kabukları olması durumunda
~ / .Bash_profile yapmanın doğru yolu burada yanıtlandı:
.Bashrc ve .bash_profile arasındaki fark
if [ -r ~/.profile ]; then . ~/.profile; fi
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac
Testi (ve profil oluşturmayı) etkinleştirmek için bunu kullanabilirsiniz
~ / .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`
# ------------------------------------------------
sonra test etmek için:
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
Dolayısıyla, RVM / virtualenv ~ / .profile, IMHO içine gitmelidir
Ama bu YAPAR DEĞİL İŞ , bazen ...
Örneğin, virualenvwrapper yalnızca Xsession'ı çalıştıran kabuk "orijinal" bir bash ise çalışır (BASH_VERSION dışa aktarılır)
Bir çizgi sistemindeyseniz, ortam değişkeni ve yol ayarı çalışır, ancak virualenvwrapper işlev tanımı, komut dosyası POSIX uyumlu olmadığı için çalışmaz.
Komut dosyası herhangi bir hata vermez ancak herhangi bir "çalışma" tanımı olmadan sona erer .
Böylece , doğrudan X'ten başlatılan istemciden doğru python yürütmesini etkinleştirmek için ortamı ~ / .profile içinde ayarlayabilirsiniz :
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
Ama virualenvwrapper için iki seçeneğiniz var:
- kaynak o ~ / .bash_profile veya ~ / .zprofile (veya ~ / .zlogin) giriş kabuğu olarak görev gördüğü
- komut dosyasını ~ / .bashrc veya ~ / zshrc içine ekleyin
Bu, X istemcilerinin (örneğin emacs) grafiksel olandan değil terminal kabuğundan başlatılması gerektiği anlamına gelir!
"Tatmin olamıyorum ..."