Есть ли вред в использовании переменных, которые не установлены?

Несуществующие переменные всегда будут вычисляться в пустую строку при расширении как $FOO или (эквивалентно) ${FOO}, и в зависимости от этого нет никакого вреда, за исключением одного конкретного случая:

Если кто-то вызывал в текущей оболочке set -u до того, как вы попытались использовать эту переменную, то он включил эту настройку:

              -u      Treat unset variables as an error when performing param-
                      eter  expansion.   If expansion is attempted on an unset
                      variable, the shell prints an error message, and, if not
                      interactive, exits with a non-zero status.

Это означает, что если вы пишете функцию, которая предназначена для исходного кода в сценарии, который контролируется кем-то другим, вам может понадобиться быть параноиком в использовании переменных unset - иначе, если они использовали set -u до вызова вашей функции, их сценарий выйдет с сообщением об ошибке при первой же попытке расширения переменной unset.

Если вы пишете свой собственный скрипт, то нет ничего плохого в том, чтобы рассчитывать на переменные unset, расширяющиеся до пустой строки.

РЕДАКТИРОВАНИЕ - Также, просто мысль - поскольку вы ставите все это в зависимость от того, доступны ли возможности цвета терминала для вашего терминала, почему бы на самом деле не использовать терминал для генерации последовательностей, а не жестко кодировать значения vt100? Что-то вроде:

if [ -n "$force_color_prompt" ] && type tput &>/dev/null; then
    GREEN="$(tput setaf 2)$(tput bold)"
    DIM="$(tput dim)"
    RESET="$(tput sgr0)"
fi

Это может дать вам некоторую переносимость на другие терминалы (хотя, по общему признанию, количество терминалов, которые не используют показываемые вами коды, невелико и уменьшается). Это также может потерять некоторую переносимость, так как некоторые возможности могут не существовать на некоторых платформах в зависимости от того, насколько правильны определения терминалов. YMMV.

Одной из самых уникальных особенностей POSIX-совместимого языка сценариев оболочки является расширение параметра . Его можно использовать различными способами для выполнения задач, которые обычно не связаны со значениями переменных. В оболочке переменная может быть чем-то большим, чем просто значением - она ​​может быть элементом действия. У него есть возможность проверить себя. И это происходит явно - без необходимости устанавливать параметры оболочки.

Например, ваш код может выглядеть так:

N= ERR='error encountered - exiting' 
: ${force_color_prompt?"$ERR"}
/usr/bin/tput setaf >/dev/null 2>&1 || ${N:?"$ERR"}
: "${GREEN:=\033[1;32m}" "${DIM:=\033[2m}" "${RESET:=\033[00m}"
printf %b\\n \
    "Oh, ${GREEN}green${RESET} world, ${DIM}don't desert me now...${RESET}"

Переменная $ N явно установлена ​​на пустую строку, и поэтому при ее оценке с помощью $ {N :?} форма расширения параметров его родительской оболочки автоматически завершается, и оператор, следующий за ? , также оценивается на предмет раскрытия, результаты которого выводятся на stderr . То же самое и с $ force_color_prompt - если он не установлен, сценарий завершается с ошибкой и выводит $ ERR в stderr - все автоматически.

$ GREEN $ RESET и $ DIM установлены на значения, которые вы определили, если они в настоящее время не установлены или установлены на '' пустая строка. Это позволяет передавать их значения в сценарий как переменные среды. Например, если бы приведенный выше фрагмент был в сценарии с именем greenworld.sh , и я назвал бы его так:

GREEN="$(tput setaf 2)$(tput bold)" greenworld.sh

Тогда $ GREEN не будет сброшен в содержимом сценария и вместо этого унаследовал бы явное значение, которое я для него установил. Это делает сценарии оболочки гибкими.

И использовать tput таким образом, как рекомендовал godlygeek, я рекомендую, например, второй.

В оболочке неустановленная переменная иногда может быть так же полезна, как и установленная. Вот другой пример:

set -- * 
while ${1+:} false ; do
    #do stuff until all positionals are shifted away
shift ; done

В этом примере, пока определен первый параметр, он будет расширяться до встроенной функции оболочки : null, что, следовательно, приведет к следующему вызову false . нет операции. Но как только все позиционные параметры были , сдвиг удален $ {1} не расширяется таким образом, и вызывается false , и а цикл завершается. Вы можете сделать бесчисленное количество вариантов этого.

При нормальном использовании, т.е. когда вы просто разворачиваете переменные, переменную сброса рассматривают как пустую во всех оболочках Bourne/POSIX-style. Исключение - когда устанавливает сброс-o иначе ,-u набора в действительности, в этом случае оболочка повысит ошибку, при попытке получить доступ к значению переменной сброса (см. ответ godlygeek ).

существуют способы протестировать, сброшена ли переменная или пуста; например, конструкция $ {панель нечто} расширяется до значения нечто , если это установлено (даже если это пусто), и к панель , если нечто сброшено;
$ {foo:-панель} (с дополнительным двоеточием) рассматривает пустую переменную, как будто это было сброшено. Другие подобные конструкции расширения $ {foo+bar} , $ {нечто? панель} , $ {foo=bar} ведут себя аналогично. Пустая переменная также появится в выводе , устанавливает и экспорт (если экспортируется), среди других различий. Вы только столкнетесь с этими различиями, если вы захотите.

Однако существует другая причина для , всегда инициализируют переменные : как ты знаешь, что переменная действительно сброшена? Вызывающая сторона, возможно, определила подобную переменную в ее собственных целях. Если вызывающая сторона будет некоторой другой частью того же сценария, то ваше использование в функции перезапишет вызывающую сторону, если вы не объявите переменную как локальную (который только возможен в ksh/bash/zsh), таким образом, столкновения имени переменной являются проблемой так или иначе. Но это может также произойти, что переменная присутствует в среде, потому что кто-то еще выбрал то же имя переменной как вы. Существует своего рода конвенция использовать строчные названия переменных оболочки и прописные названия переменных среды, но она не решает все столкновения, и она не сопровождается универсально.

$ export DIM=1 SUM=42
$ bash
Oh, green world, 1don't desert me now...