Нещодавно я помітив, що у нас є 3 варіанти встановлення змінних середовища:
export envVar1=1setenv envVar2=2env envVAr3=3Якщо є інші способи, просвітліть нас.
Коли я повинен віддавати перевагу одному перед іншим? Просимо запропонувати вказівки.
Що стосується сумісності оболонок, яка є найбільш експансивною (охоплює більше діалектів оболонок)?
Я вже помітив цю відповідь, але хочу розширити це питання envта використовувати рекомендації щодо використання.
Відповіді:
export VARIABLE_NAME='some value'це спосіб встановити змінну середовища в будь-який POSIX-сумісної оболонці ( sh, dash, bash, ksh, і т.д.; також ЗШ). Якщо змінна вже має значення, ви можете використовувати export VARIABLE_NAMEїї для змінної середовища, не змінюючи її значення.
Оболонки Pre-POSIX Bourne не підтримували це, тому ви побачите сценарії, які уникають export VARIABLE_NAME='some value'та використовують VARIABLE_NAME='some value'; export VARIABLE_NAMEнатомість. Але снаряди перед POSIX Bourne в наш час надзвичайно рідкісні.
setenv VARIABLE_NAME='some value'синтаксис csh для встановлення змінної середовища. setenvне існує sh, і csh вкрай рідко використовується в сценаріях і був перевершений bash для інтерактивного використання протягом останніх 20 років (і zsh ще довше), тому ви можете забути про нього, якщо не зіткнетеся з ним.
envКоманда дуже рідко використовується тільки в хатину ліній . Якщо викликається без аргументів, він відображає середовище, але exportробить це краще (сортується та часто цитується для розмежування нових рядків у значеннях від нових рядків, що розділяють значення). При виклику аргументів вона запускає команду з додатковими змінними середовища, але та сама команда без envтакож працює ( VAR=value mycommandпрацює mycommandз VARвстановленим на value, точно так само env VAR=value mycommand). Причина env, корисна в рядку shebang, полягає в тому, що вона виконує PATHпошук, і, трапляється, не робить нічого іншого, коли викликається ім'я команди. envКоманда може бути корисна для виконання команди з допомогою всього декількох змінних оточення з-iабо без параметрів для відображення середовища, включаючи змінні з недійсними іменами, які оболонка не імпортує.
Встановлення такої змінної, як VAR='asdf'середовище, залишає немодифікованим, це означає, що програми, запущені в одному сеансі, нічого не знають VARі не зможуть отримати доступ до неї. Ви хочете такої поведінки під час написання скриптів оболонок.
exportз іншого боку, це вбудований bash, який модифікує середовище, завдяки чому експортована змінна видима для дочірніх процесів, породжених у поточному сеансі. Ви можете домогтися того ж, бігаючи VAR='asdf' %program_name%.
envце не вбудований, а сама програма. На поверхні це працює точно так само, як коли ти VAR='asdf' %program_name%, але на нижньому рівні все стає дещо складніше. По-перше, envзапускається. Він змінює середовище, потім виконує команду із заданими аргументами. Таку саму поведінку ви можете отримати у власному коді, використовуючи exec (3) системний виклик .
setenvзнаходиться просто exportв сімейних оболонках csh, як зазначено у вашій відповіді.
Є кілька запитань з відповідями, які відповідають на це:
Різниця між змінними оболонками, які експортуються, та тими, які не знаходяться в bash
Яка різниця у використанні між змінними оболонки та змінними середовища?
(тощо)
VAR=asdfоновлює навколишнє середовище, якщоVARвоно вже було в середовищі. (Це не було правдою в оригінальній оболонці Борна.)