Чому я повинен "джерело .profile" у кожному відкритому терміналі?

Коли ми змінюємо якусь змінну в ~/.profileUbuntu, тоді виконуємо команду source .profile. Тоді зміна діє лише в цьому терміналі. Якщо ми відкриємо новий термінал, нам доведеться виконати команду source .profileще раз. Отже, схоже, що у різних терміналів є власне середовище, хоча вони можуть належати одному користувачеві.

Яка перевага зробити так, щоб кожен термінал мав свій власний шлях оточення? Здається, що було б краще, якщо різний термінал, який належав одному і тому ж користувачу, поділяв одну і ту ж змінну середовища.

Причиною цього є те, що ~/.profileлише джерела вхідних оболонок. Коли ви відкриєте нове вікно терміналу, оболонка, що запускається, за замовчуванням є оболонкою без входу. Якщо ви виходите з системи та знову входите в систему, то зміна ~/.profileбуде ефективною у всіх ваших терміналах, оскільки вона ~/.profileз'являється під час входу в сеанс.

Справа не в тому, що різні вікна терміналів мають інше середовище, але те, що джерело ~/.profileвиконується лише ~/.profileв поточній оболонці (саме це sourceробить команда).

На противагу цьому, зміна на ~/.bashrcнегайно вплине на будь-яке нове вікно терміналу, яке ви відкриєте, або будь-яку оболонку Bash, яку ви починаєте, набравши текст bash, оскільки вона розміщена у всіх інтерактивних оболонках Bash.

Змінні середовища не тільки для налаштувань користувача. Вони є загальним механізмом передачі різноманітної інформації про налаштування від батьківського процесу до дочірніх процесів, які він починає.

Є численні випадки, коли процес встановлює конкретні змінні середовища, щоб впливати на лише процеси, які він починає. Наприклад, скрипт може навмисно скинути параметри локалі для команд, які він запускає, таким чином, щоб він міг аналізувати вихід з них. Сценарії побудови для багатьох великих програмних пакетів використовують вкладені виклики, makeякі координують один одного через змінні середовища. Спеціалізовані інструменти можуть потребувати зміни умов роботи інших програм, які вони починають, виконуючи трюки з $ LD_PRELOAD або $ PATH.

Якщо щось, що користувач робить у іншому вікні, а довга компіляція працює в іншому, просто магічно змінить змінні середовища всіх його процесів за їх спиною, то виникне безумство та хаос.

Інші змінні середовища містять інформацію про конкретний сеанс, в якому запускається процес. Програми очікують, що $ TERM опише набір команд конкретного терміналу (або емулятора терміналу), до якого вони підключені; що робить загальне налаштування для кожного користувача неможливим увійти в одну і ту ж систему з кількома різними терміналами. Навіть якщо у вас є лише одна частина апаратного забезпечення терміналу, і ви ніколи не входите віддалено, такі програми, як, наприклад, screenзалежать від встановлення іншого $ TERM для процесів, що працюють в їх сеансі.

Краще питання: чому ми використовуємо механізм зв’язку "процес до підпроцесу" для налаштувань уподобань користувачів, а не базу даних для кожного користувача?

Відповідь: Оскільки вона працює досить добре, а переваги створення бази даних на кожного користувача недостатньо великі, щоб працювати над зміною всього використання, що замість змінних середовища.

(Я можу думати дуже мало налаштувань переваг там , де не було б деякі випадки використання , де це зручно , щоб змінити їх тільки для виконання одного сценарію, наприклад. Так що , щоб не втратити функціональність, все ще необхідно буде перевизначення шляхом змінні середовища, що призводить до додаткової складності та більше заплутаних користувачів).

Не так, як альтернативи не існують . Наприклад, ресурси X є на сеанс показу, а не на процес. Але їм важко отримати доступ до програм командного рядка - і програмам командного рядка зазвичай потрібно працювати для віддалених входів, до яких навіть не має X-сервера.