/Etc/profile.d dosyasındaki scriptler ne yapar?

Linux Komut Satırı ve Shell Komut Dosyası İncil'den temel kabuk komut dosyası hakkında okuyorum .

/etc/profileDosyanın, ortam değişkenlerini Bash kabuğunun başlangıcında ayarladığını söylüyor . /etc/profile.dDizin da kabuk tarafından başlangıç anda yürütülür uygulamaya özgü başlatma dosyalarını içeren diğer komut içeriyor.

• Bu dosyalar neden /etc/profileBash'in başlatılması için kritik öneme sahip olduklarının bir parçası değiller?

• Bu dosyalar uygulamaya özgü başlangıç ​​dosyalarıysa Bash başlangıcı için kritik değilse, neden başlangıç ​​işleminin bir parçası? Neden yalnızca ayarları içeren belirli uygulamalar yürütüldüğünde çalışmıyorlar?

Bash başlangıcı için de kritik öneme sahipse, bu dosyalar neden / etc / profile'nin parçası değil?

"Neden sadece dev bir senaryoda birleştirilmiyorlar?"

1. Çünkü bu senaryolardan sorumlu olan insanlar için bir bakım kabusu olur.
2. Komut dosyalarının bağımsız modüller olarak yüklenmesi, tüm sistemi daha dinamik bir şekilde ayarlanabilmesini sağlar - diğer komut dosyaları, diğerlerini etkilemeden eklenebilir ve kaldırılabilir. Vb.
3. Çünkü onlar / etc / profile üzerinden yüklenir, bu da zaten aynı şekilde bash "profile" nin bir parçası olur.

Bu dosyalar uygulamaya özgü başlangıç ​​dosyalarıysa Bash başlangıcı için kritik değilse, neden başlangıç ​​işleminin bir parçası? Neden yalnızca ayarları içeren belirli uygulamalar yürütüldüğünde çalışmıyorlar?

Bu bana ikiye böleceğim daha geniş bir tasarım felsefesi sorusu gibi görünüyor. İlk soru, kabuk ortamını kullanmanın değeri ve uygunluğu ile ilgilidir. Pozitif değeri var mı? Evet, yararlıdır. Tüm yapılandırma sorunlarına en iyi çözüm mü? Hayır, ancak basit parametreleri yönetmek için çok etkilidir ve ayrıca geniş çapta tanınır ve anlaşılır. Aksine, bu tür şeyleri heterojen bir şekilde yapılandırmaya karar vermenin aksine, $ PATH ayrı bir bağımsız araçla yönetilebilir, $ EDITOR gibi tercih edilen araçlar bir yerde bir sqlite dosyasında olabilir, $ LC lang sayfalarında bir metin dosyasında olabilir. başka bir yere özel biçim, vb - yalnızca env değişkenlerini kullanmaz ve/etc/profile.daniden daha basit görünüyor? Muhtemelen env değişkeninin ne olduğunu, nasıl çalıştıklarını ve nasıl kullanacaklarını zaten biliyorsunuz, vs. "çevre" olarak adlandırılan şeyin 5 farklı her yönü için 5 farklı mekanizma öğrenmek .

İkinci soru, "Başlama için uygun zaman mıdır?", Bu da çok verimli olmadığına itiraz eder (tüm bu verilerin kullanılıp kullanılamayacağı, vb.). Fakat:

• Gerçekçi olarak, bu kadar veri değil, çünkü kısmen aklı başında hiç kimse onu birkaç basit parametreden daha fazla kullanmayacaktı (çünkü bir uygulamayı yapılandırmanın başka yolları da var).
• Akıllıca kullanılırsa, sıkça çağrılan şeylerle ilgili olarak, her seferinde bir yerde bir dosyadan varsayılan $ CFLAGS ayarının gccyapılması daha az etkili olacaktır. İlgili bellek miktarının yine sonsuz olduğunu unutmayın.
• Birden fazla uygulamanın dahil olabileceği sistemik şeyleri içerebilir ve kabuk ortak bir zemindir .

Bu listeye daha fazlası eklenebilir, ancak umarım bu size konunun avantajları ve dezavantajları hakkında bir fikir verir - en büyük “profesyonel” ve en büyük “aleyhte”, bunun küresel bir ad alanı olduğudur.

Bu dosyalar bir uygulamaya özeldir, ancak uygulama başlatıldığında değil kabuk başlatma sırasında kaynaklanır. Burada bir konfigürasyon dizini, başka birçok yerde bulunması nedeniyle kullanılır. Bu, bir uygulamanın veya yazılım paketinin yapılandırmaları değiştirmesine izin verir. Bu, bölünmüş bir konfigürasyon olmadan mümkün olmaz, çünkü kullanıcı tarafından da değiştirilebilen tek bir konfigürasyon dosyasını yönetmeye / güncellemeye çalışan birden fazla paket buggy ve dağınık olur.

Ayrıca bir not, /etc/profilesadece kabuktan değil bütün kabuklardan kaynaklanır. Bash özel yapılandırma dosyası bashrc ve yalnızca etkileşimli kabukları için kaynak.

jordanm'ın cevabı yanlış. /etc/profilebütün mermilerden kaynaklanmıyor. Sizin de belirttiğiniz gibi, kaynaklı değil csh, tcsh- Emin değilim zsh. shKorn Shell ( ksh) ve BASH ( bash) gibi Bourne kabuğu ( ) türevleri ile elde edilir . cshkullanır /etc/login. Sadece Borne Shell türevlerini kullanma eğiliminde olan insanlar, diğer kabukları da varolma eğilimindedir. /etc/profile"Tüm kullanıcılara" uygulanmasını beklemek için bir şeyler eklerler ve sonra garip C Shell kullanıcısı (ve biz tuhaf bir yeriz) yapılandırdıkları şeylere sahip olmadıklarında şaşırırlar /etc/profile.

Buna rağmen, insanlar var olan diğer Borne Kabuğu türev kabukları hakkında unutma eğilimindedirler. Kullandıkları takdirde bashya ksh, onlar sözdizimi eklemek için çekinmeyin /etc/profilebir değişken tanımlama ve aynı hat üzerinde ihracat demek gibi o Bourne Kabuğu'nda geçerli değil. Sonra, bazı senaryoları alırsınız #!/bin/shve sözdiziminde boğulur. /etc/profileBourne Shell uyumlu sözdizimine bağlı kalmalı.

Aynı şekilde, kendi başınıza da yapmalısınız .profile( .bash_profilebazı bash sözdizimi istiyorsanız kullanın) - biraz fazladan yazarak olabilir, ama hepinizi bir kez daha fazla yazmaktır. Referans ${HOME}ve değil ~, vb. Unix'in bazı lezzetleri, cron işleri altından geçiyor sh, her bir hattınız Makefileişleniyor sh, bu nedenle UNIX'in çeşitli lezzetleriyle çalışıyorsanız, .profileBourne kabuğunuzu uyumlu tutmak gerçekten işe yarar . Bir SysAdmin olarak, .profileBourne Shell ile uyumlu olmalarını düzelterek birine kaç kez yardım ettiğimi söyleyemem .

Linux'ta, /bin/shbir bağlantıdır /bin/bashve bunu çalıştırdığınızda, bu Bourne Shell destekleyen tek şey kendini sınırlar (teoride) çalıştırmak için kullanılan bir yol arar ve. Aynı şekilde, viLinux'ta gerçekten vim, yine kendini sınırlıyor. Arada sırada "sızdırma" özellikleri görüyorsunuz. Zaman vimzaman , yazarların "vi geriye dönük uyumluluk" modunda bunu devre dışı bırakmayı unuttuğu için destekleyici bir vişey yapmamış gibi davranmak . Öyle davranmak gibi bazı "kanama" özellikleri varsa şaşırmam . Bazı özellikler "Linux'ta Borne Shell'de çalışıyorsa", ancak System V veya BSD tabanlı bir UNIX'te (AIX, OpenBSD vb.) Çalışmıyorsa şaşıracaksınız.vimvivimbashsh