Apa yang dilakukan skrip di /etc/profile.d?

85

Saya membaca tentang skrip shell dasar dari Linux Command Line dan Shell Scripting Bible .

Dikatakan bahwa /etc/profilefile menetapkan variabel lingkungan saat startup Bash shell. The /etc/profile.ddirektori berisi skrip lain yang berisi file startup aplikasi-spesifik, yang juga dilaksanakan pada saat startup oleh shell.

  • Mengapa file-file ini bukan bagian dari /etc/profilejika mereka juga penting untuk startup Bash?

  • Jika file-file ini adalah file startup khusus aplikasi yang tidak penting untuk startup Bash, lalu mengapa mereka bagian dari proses startup? Mengapa mereka tidak berjalan hanya ketika aplikasi spesifik, yang mengandung pengaturan, dieksekusi?

asheeshr
sumber

Jawaban:

71

Mengapa file-file ini bukan bagian dari / etc / profile jika mereka juga penting untuk startup Bash?

Jika Anda bermaksud, "Mengapa mereka tidak hanya digabungkan menjadi satu skrip raksasa?", Jawabannya adalah:

  1. Karena itu akan menjadi mimpi buruk pemeliharaan bagi orang-orang yang bertanggung jawab atas skrip.
  2. Karena memiliki skrip dimuat sebagai modul independen membuat keseluruhan sistem lebih dinamis disesuaikan - skrip individu dapat ditambahkan dan dihapus tanpa mempengaruhi yang lain. Dll
  3. Karena mereka dimuat melalui / etc / profile yang menjadikan mereka bagian dari "profil" bash dengan cara yang sama.

Jika file-file ini adalah file startup khusus aplikasi yang tidak penting untuk startup Bash, lalu mengapa mereka bagian dari proses startup? Mengapa mereka tidak berjalan hanya ketika aplikasi spesifik, yang mengandung pengaturan, dieksekusi?

Bagi saya itu seperti pertanyaan filosofi desain yang lebih luas yang akan saya bagi menjadi dua. Pertanyaan pertama adalah tentang nilai dan kesesuaian menggunakan lingkungan shell. Apakah ini memiliki nilai positif? Ya, ini berguna. Apakah ini solusi terbaik untuk semua masalah konfigurasi? Tidak, tetapi sangat efisien untuk mengelola parameter sederhana, dan juga diakui dan dipahami secara luas. Berbeda dengan yang dikatakan, memutuskan untuk mengkonfigurasi hal-hal seperti itu secara heterogen, mungkin $ PATH dapat dikelola oleh alat independen yang terpisah, alat yang disukai seperti $ EDITOR dapat berada dalam file sqlite di suatu tempat, $ LC hal-hal bisa dalam file teks dengan file format kustom di tempat lain, dll - tidak hanya menggunakan variabel env dan/etc/profile.dtiba-tiba terasa lebih sederhana? Anda mungkin sudah tahu apa variabel env itu, bagaimana mereka bekerja dan bagaimana menggunakannya, vs. belajar 5 mekanisme yang sama sekali berbeda untuk 5 aspek berbeda di mana-mana dari apa yang secara tepat disebut "lingkungan".

Pertanyaan kedua adalah, "Apakah startup adalah waktu yang tepat untuk ini?", Yang menimbulkan keberatan bahwa itu tidak terlalu efisien (semua data yang mungkin atau mungkin tidak digunakan, dll). Tapi:

  • Secara realistis, ini tidak terlalu banyak data, sebagian karena tidak ada orang waras yang akan menggunakannya untuk lebih dari beberapa parameter sederhana (karena ada cara lain untuk mengkonfigurasi aplikasi).
  • Jika digunakan secara bijak, berkenaan dengan hal-hal yang biasa dipanggil, maka pengaturan, misalnya, default $ CFLAGS dari file di suatu tempat setiap kali Anda memohon gccakan kurang efisien. Perlu diingat bahwa jumlah memori yang terlibat, sekali lagi, sangat kecil.
  • Ini dapat melibatkan hal-hal sistemik yang melibatkan lebih dari satu aplikasi, dan shell adalah landasan bersama .

Lebih banyak dapat ditambahkan ke daftar itu, tetapi mudah-mudahan ini memberi Anda beberapa gagasan tentang pro dan kontra dari masalah ini - 'pro' utama dan 'con' utama adalah bahwa itu adalah namespace global.

goldilocks
sumber
Does it have positive ... and understood.Apa yang ingin kamu katakan di sini? Saya mengerti segalanya selain paragraf itu.
asheeshr
3
Lingkungan shell umumnya digunakan untuk mengkonfigurasi shell itu sendiri dan alat lain di mana-mana. Ini bukan satu - satunya cara konfigurasi dapat dilakukan, jadi perlu dipertimbangkan apakah lingkungan lebih baik atau lebih buruk daripada opsi lainnya. Dengan memiliki "nilai positif", maksud saya bahwa menggunakan lingkungan tampaknya memiliki beberapa keunggulan dibandingkan opsi lain setidaknya WRT "mengelola parameter sederhana" - yaitu bahwa ia sangat efisien dan "diakui dan dipahami secara luas" ... dan saya Saya akan menambahkan sedikit untuk menjelaskan frasa itu lebih lanjut.
goldilocks
Bagaimana dengan menambahkan baris ke profile.local? Apakah ini dapat diterima vs membuat skrip di folder profile.d?
Avindra Goolcharan
@AvindraGoolcharan Distro yang berbeda mungkin menggunakan skema berbeda untuk hal semacam ini. The profile.ddirektori hanya bekerja karena isinya adalah bersumber oleh /etc/profile, yang ditentukan oleh kerang seperti bash sebagai file startup (lihat doa di man bash); jika Anda mengedit /etc/profile, Anda dapat menonaktifkan /etc/profile.d. /etc/profile.localtampaknya merupakan penemuan SUSE, mungkin bersumber dari suatu tempat seperti /etc/profilesehingga Anda dapat meletakkan barang-barang Anda sendiri di sana. Namun, jika Anda memindahkannya ke sistem non SUSE dan tidak melakukan penyesuaian lain, itu tidak akan digunakan oleh apa pun.
goldilocks
Gotcha, itu sangat jelas. Ya kami menggunakan SUSE di pekerjaan saya. / etc / profile. sepertinya taruhan yang jauh lebih baik.
Avindra Goolcharan
13

File-file itu khusus untuk suatu aplikasi, tetapi bersumber pada shell startup, bukan ketika aplikasi dimulai. Direktori konfigurasi digunakan di sini untuk alasan yang sama dengan yang ditemukan di banyak tempat lain. Ini memungkinkan aplikasi atau paket perangkat lunak untuk memodifikasi konfigurasi. Ini tidak akan mungkin terjadi tanpa konfigurasi split, karena beberapa paket yang mencoba mengelola / memperbarui file konfigurasi tunggal yang juga dapat dimodifikasi oleh pengguna akan menjadi buggy dan berantakan.

Juga catatan samping, /etc/profilebersumber dari semua kerang, bukan hanya bash. File konfigurasi spesifik bash adalah bashrc dan hanya bersumber untuk shell interaktif.

jordanm
sumber
3
Paragraf kedua menarik. Karena cangkang yang berbeda mendukung sintaks yang berbeda, ini akan mengharuskan adanya sintaksis umum yang signifikan. Benar untuk bash dan sh, tapi saya rasa tidak untuk orang lain seperti csh atau tcsh, yang memiliki skrip startup login global mereka sendiri. Pada banyak sistem, / bin / sh hanyalah tautan ke / bin / bash. Tetapi bash memodifikasi perilakunya agar sesuai dengan posix ketika dipanggil sebagai sh. Jadi orang akan berpikir bahwa penulis skrip di /etc/profile.d perlu berhati-hati untuk menghindari menggunakan ekstensi bash di luar subset posix.
sootsnoot
Di linux ada file .csh dan .sh yang terpisah untuk dua jenis shell utama.
stark
0

Jawaban jordanm salah. /etc/profiletidak bersumber dari semua kerang. Seperti yang Anda tunjukkan, itu tidak bersumber dari csh, tcsh- Saya tidak yakin tentang zsh. Ini bersumber dari shturunan Bourne shell ( ), seperti Korn Shell ( ksh) dan BASH ( bash). cshmenggunakan /etc/login. Orang-orang yang cenderung menggunakan turunan Borne Shell cenderung melupakan cangkang lain yang ada. Mereka menambahkan sesuatu yang /etc/profilediharapkan berlaku untuk "semua pengguna" dan kemudian terkejut ketika pengguna C Shell aneh (dan kami banyak yang aneh) tidak memiliki hal-hal yang mereka konfigurasikan /etc/profile.

Meski begitu, orang cenderung melupakan cangkang turunan Borne Shell lain yang ada. Jika mereka menggunakan bashatau ksh, mereka merasa bebas untuk menambahkan sintaks /etc/profileyang tidak valid di Bourne Shell, seperti mengatakan mendefinisikan variabel dan mengekspornya pada baris yang sama. Kemudian Anda mendapatkan beberapa skrip yang berfungsi #!/bin/shdan tersedak sintaksisnya. /etc/profileharus tetap menggunakan sintaks yang kompatibel dengan Bourne Shell.

Demikian juga, Anda harus tetap menggunakan itu sendiri .profile(gunakan .bash_profilejika Anda ingin sintaks bash) - ini mungkin sedikit mengetik ekstra, tetapi itu adalah mengetik tambahan yang Anda lakukan sekaligus. Referensi ${HOME}dan bukan ~, dll. Beberapa rasa Unix, pekerjaan cron berjalan di bawah sh, setiap baris Anda Makefilediproses oleh sh, jadi jika Anda bekerja di berbagai rasa UNIX, itu benar-benar bermanfaat untuk menjaga agar .profileshell Bourne Anda kompatibel. Sebagai SysAdmin, saya tidak bisa memberi tahu Anda berapa kali saya telah membantu seseorang dengan memperbaiki mereka .profileagar kompatibel dengan Bourne Shell.

Di Linux, /bin/shadalah tautan ke /bin/bashdan ketika Anda menjalankannya, itu terlihat jalur yang digunakan untuk menjalankannya, dan (secara teori) membatasi dirinya hanya untuk hal-hal yang didukung Bourne Shell. Demikian juga, vidi Linux benar-benar vim, sekali lagi membatasi dirinya. Terkadang Anda melihat fitur "bleed through". Kadang vim- kadang berpura-pura viakan melakukan sesuatu yang vimmendukung yang vitidak karena penulis vimlupa menonaktifkan ini dalam mode "vi backwards kompatibilitas". Saya tidak akan terkejut jika bashberpura-pura shmemiliki beberapa fitur "berdarah" yang serupa. Tidak akan terkejut jika beberapa fitur "berfungsi pada Borne Shell di Linux", tetapi tidak pada UNIX berbasis Sistem V atau BSD (AIX, OpenBSD, dll.).

Damocles
sumber
Apakah Anda yakin "di Linux /bin/shadalah tautan ke /bin/bash"? Itu pernyataan yang bagus.
41754