Mengapa saya harus `source .profile` di setiap terminal yang saya buka?


10

Ketika kita mengubah beberapa variabel di ~/.profiledalam Ubuntu, maka kita menjalankan perintah source .profile. Maka perubahan hanya efektif di terminal ini. Jika kita membuka terminal baru, kita harus menjalankan perintah source .profilelagi. Jadi sepertinya terminal yang berbeda memiliki lingkungan mereka sendiri meskipun mereka mungkin milik pengguna yang sama.

Apa keuntungan membuat setiap terminal memiliki jalur lingkungannya sendiri? Tampaknya akan lebih baik jika terminal berbeda milik pengguna yang sama berbagi variabel lingkungan yang sama.



Jika "shell" login Anda adalah GUI, itu tidak membantu banyak untuk mengatur var di skrip login sh bukan GUI Anda.
ikegami

Jawaban:


14

Alasannya adalah ~/.profileini hanya bersumber dari shell login. Ketika Anda membuka jendela terminal baru, shell yang memulai adalah shell non-login secara default. Jika Anda keluar, dan masuk kembali, perubahan ~/.profileakan efektif di semua terminal Anda, karena ~/.profilebersumber ketika Anda masuk ke sesi Anda.

Ini bukan kasus bahwa windows terminal yang berbeda memiliki lingkungan yang berbeda, tetapi bahwa sumber ~/.profilehanya dijalankan ~/.profiledi shell saat ini (itulah yang dilakukan sourceperintah).

Sebaliknya, perubahan ~/.bashrcakan segera memengaruhi jendela terminal baru yang Anda buka, atau Bash shell yang Anda mulai dengan mengetik bash, karena bersumber dari semua shell Bash interaktif.


3

Variabel lingkungan tidak hanya untuk preferensi pengguna. Mereka adalah mekanisme umum untuk mengkomunikasikan berbagai pengaturan informasi dari proses induk ke proses anak dimulai.

Ada banyak kasus di mana suatu proses akan menetapkan variabel lingkungan tertentu untuk mempengaruhi proses yang baru saja dimulai. Sebagai contoh, sebuah skrip mungkin dengan sengaja mengatur ulang pengaturan lokal untuk perintah-perintah yang dimulai, sehingga ia dapat mem-parsing output darinya. Skrip build untuk banyak paket perangkat lunak besar menggunakan pemanggilan bersarang dari makeyang berkoordinasi satu sama lain melalui variabel lingkungan. Alat khusus mungkin perlu mengubah kondisi kerja program lain yang mereka mulai dengan melakukan trik dengan $ LD_PRELOAD atau $ PATH.

Jika sesuatu yang dilakukan pengguna di jendela yang berbeda saat kompilasi yang lama berjalan di jendela lain hanya akan secara ajaib mengubah variabel lingkungan dari semua prosesnya di belakang, kegilaan dan kekacauan akan terjadi.

Variabel lingkungan lainnya berisi informasi tentang sesi tertentu tempat proses dimulai. Program mengharapkan $ TERM untuk menggambarkan set perintah terminal tertentu (atau terminal emulator) yang terhubung dengan mereka; membuat pengaturan umum per pengguna akan membuatnya tidak mungkin untuk masuk ke sistem yang sama dengan beberapa jenis terminal. Bahkan jika Anda hanya memiliki satu perangkat keras terminal dan tidak pernah masuk secara jarak jauh, program seperti screenbergantung pada pengaturan $ TERM yang berbeda untuk proses yang berjalan di dalam sesi mereka.

Pertanyaan yang lebih baik adalah, mengapa kita menggunakan mekanisme komunikasi proses-ke-proses untuk pengaturan preferensi pengguna, daripada database per pengguna?

Jawaban: Karena ini berfungsi dengan cukup baik dan manfaat membuat basis data per pengguna tidak cukup besar sehingga pekerjaan mengubah segala sesuatu untuk digunakan , alih - alih variabel lingkungan akan dilakukan.

(Saya bisa memikirkan sangat sedikit pengaturan preferensi di mana tidak akan ada beberapa kasus penggunaan di mana nyaman untuk mengubahnya hanya untuk mengeksekusi skrip tunggal, misalnya. Jadi agar tidak kehilangan fungsionalitas, semuanya masih perlu ditimpa oleh variabel lingkungan, yang menghasilkan kompleksitas tambahan dan pengguna yang lebih bingung).

Bukannya tidak ada alternatif . Misalnya, sumber X adalah per sesi tampilan daripada per proses. Tetapi mereka sulit diakses untuk program-program command-line - dan program-program command-line biasanya perlu bekerja untuk login jarak jauh yang bahkan tidak memiliki server X untuk terhubung.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.