Цитування в $ (заміна команди) в Bash

У моєму середовищі Bash я використовую змінні, що містять пробіли, і я використовую ці змінні в рамках заміни команд. На жаль, я не можу знайти відповідь на SE.

Який правильний спосіб цитувати мої змінні? І як мені це зробити, якщо вони вкладені?

DIRNAME=$(dirname "$FILE")

чи я цитую за межами заміни?

DIRNAME="$(dirname $FILE)"

або обидва?

DIRNAME="$(dirname "$FILE")"

або я використовую зворотні кліщі?

DIRNAME=`dirname "$FILE"`

Який правильний спосіб це зробити? І як я можу легко перевірити, чи правильно встановлені цитати?

Аби від найгіршого до кращого:

• DIRNAME="$(dirname $FILE)" не буде робити те, що ви хочете, якщо $FILEмістить пробіли або символи глобусу \[?*.
• DIRNAME=`dirname "$FILE"`технічно правильно, але зворотні посилання не рекомендуються для розширення команд через додаткову складність при їх вкладенні.
• DIRNAME=$(dirname "$FILE")правильно, але тільки тому, що це завдання . Якщо ви використовуєте підстановку команд у будь-якому іншому контексті, наприклад, export DIRNAME=$(dirname "$FILE")або du $(dirname "$FILE"), відсутність лапок спричинить проблеми, якщо результат розширення містить пробіли або символи глобулю.
• DIRNAME="$(dirname "$FILE")"є рекомендованим способом. Ви можете замінити DIRNAME=команду та пробіл, не змінюючи нічого іншого, і dirnameотримаєте правильний рядок.

Щоб ще більше покращитись:

• DIRNAME="$(dirname -- "$FILE")"працює, якщо $FILEпочинається з тире.
• DIRNAME="$(dirname -- "$FILE"; printf x)" && DIRNAME="${DIRNAME%?x}"працює, навіть якщо $FILEзакінчується новим рядком, оскільки $()відсікає нові рядки в кінці виводу та dirnameвиводить новий рядок після результату. Шееш dirname, чому ти повинен бути іншим?

Ви можете вкладати розширення команд скільки завгодно. З $()вами завжди створює новий контекст квотування, так що ви можете зробити що - щось на зразок цього:

foo "$(bar "$(baz "$(ban "bla")")")"

Ви не хочете пробувати це із задніми посиланнями.

Ви завжди можете показувати ефекти змінного котирування за допомогою printf.

Розділення слів зроблено на var1:

$ var1="hello     world"
$ printf '[%s]\n' $var1
[hello]
[world]

var1 цитується, тож жодне слово розщеплення:

$ printf '[%s]\n' "$var1"
[hello     world]

Розбиття слова var1всередині $(), еквівалентно echo "hello" "world":

$ var2=$(echo $var1)
$ printf '[%s]\n' "$var2"
[hello world]

Немає розділення слів var1, немає проблеми з не цитуванням $():

$ var2=$(echo "$var1")
$ printf '[%s]\n' "$var2"
[hello     world]

Розділення слів var1знову:

$ var2="$(echo $var1)"
$ printf '[%s]\n' "$var2"
[hello world]

Цитуючи обидва, найпростіший спосіб бути впевненим.

$ var2="$(echo "$var1")"
$ printf '[%s]\n' "$var2"
[hello     world]

Проблема глобалізації

Не цитування змінної також може призвести до глобального розширення її вмісту:

$ mkdir test; cd test; touch file1 file2
$ var="*"
$ printf '[%s]\n' $var
[file1]
[file2]
$ printf '[%s]\n' "$var"
[*]

Зауважте, це відбувається лише після розширення змінної. Не потрібно цитувати глобус під час присвоєння:

$ var=*
$ printf '[%s]\n' $var
[file1]
[file2]
$ printf '[%s]\n' "$var"
[*]

Використовуйте set -fдля відключення такої поведінки:

$ set -f
$ var=*
$ printf '[%s]\n' $var
[*]

І set +fщоб його знову ввімкнути:

$ set +f
$ printf '[%s]\n' $var
[file1]
[file2]

Доповнення до прийнятої відповіді:

Хоча я, як правило, погоджуюся з відповіддю @ l0b0 тут, я підозрюю, що розміщення оголених задників у списку "найгіршого до найкращого" є частково результатом припущення, яке $(...)є повсюдно. Я усвідомлюю, що питання задає Bash, але є багато випадків, коли Bash, як виявляється, означає /bin/sh, що, можливо, не завжди є повною оболонкою Bourne Again.

Зокрема, звичайна оболонка Борна не знатиме, що з цим робити $(...), тому сценарії, які стверджують, що сумісні з нею (наприклад, через #!/bin/shлінію shebang), швидше за все, недобре поводяться, якщо ними насправді керує "справжній" /bin/sh- це особливий інтерес, коли, скажімо, виробляють скрипти init або пакують попередні та пост-скрипти, і вони можуть висадити їх у дивному місці під час встановлення базової системи.

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

Сказавши все це, повсюдність оболонок, які реалізують $(...)(Bash, Dash, та ін.), Залишає нам гарне місце для того, щоб дотримуватися гарнішого, легшого в гнізді та останнім часом кращого синтаксису POSIX у більшості випадків, для всі причини @ l0b0 згадує.

Убік: це також періодично з’являється на StackOverflow -

• Підстановка команд: додаткові підписи чи знак долара / батька? [дублікат] (лютий 2012)
• Програмування оболонки: в чому різниця між $ (командою) та `командою '(січень 2011)