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

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?

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.

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.

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.).