26 декабря 2008 в 16:13

Частые ошибки программирования на Bash перевод

Качество скриптов, используемых для автоматизации и оптимизации работы системы, является залогом ее стабильности и долголетия, а также сохраняет время и нервы администратора этой системы. Несмотря на кажущуюся примитивность bash как языка программирования, он полон подводных камней и хитрых течений, способных значительно подпортить настроение как разработчику, так и администратору.

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо :-)

Данный текст является вольным переводом вики-страницы «Bash pitfalls» по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями.


1. for i in `ls *.mp3`


Одна из наиболее часто встречающихся ошибок в bash-скриптах — это циклы типа такого:

for i in `ls *.mp3`; do     # Неверно!
    some command $i         # Неверно!
done


Это не сработает, если в названии одного из файлов присутствуют пробелы, т.к. результат подстановки команды ls *.mp3 подвергается разбиению на слова. Предположим, что у нас в текущей директории есть файл 01 - Don't Eat the Yellow Snow.mp3. Цикл for пройдётся по каждому слову из названия файла и $i примет значения: "01", "-", "Don't", "Eat", "the", "Yellow", "Snow.mp3".

Заключить всю команду в кавычки тоже не получится:

for i in "`ls *.mp3`"; do   # Неверно!
    ...


Весь вывод теперь рассматривается как одно слово, и вместо того, чтобы пройтись по каждому из файлов в списке, цикл выполнится только один раз, при этом i примет значение, являющееся конкатенацией всех имён файлов через пробел.

На самом деле использование ls совершенно излишне: это внешняя команда, которая просто не нужна в данном случае. Как же тогда правильно? А вот так:

for i in *.mp3; do         # Гораздо лучше, но...
    some command "$i"      # ... см. подвох №2
done


Предоставьте bash'у самому подставлять имена файлов. Такая подстановка не будет приводить к разделению строки на слова. Каждое имя файла, удовлетворяющее шаблону *.mp3, будет рассматриваться как одно слово, и цикл пройдёт по каждому имени файла по одному разу.

Дополнительные сведения можно найти в п. 20 Bash FAQ.

Внимательный читатель должен был заметить кавычки во второй строке вышеприведённого примера. Это плавно подводит нас к подвоху №2.

2. cp $file $target


Что не так в этой команде? Вроде бы ничего особенного, если вы абсолютно точно знаете, что переменные $file и $target не содержат пробелов или подстановочных символов.

Но если вы не знаете, что за файлы вам попадутся, или вы параноик, или просто пытаетесь следовать хорошему стилю bash-программирования, то вы заключите названия ваших переменных в кавычки, чтобы не подвергать их разбиению на слова.

cp "$file" "$target"


Без двойных кавычек скрипт выполнит команду cp 01 - Don't Eat the Yellow Snow.mp3 /mnt/usb, и вы получите массу ошибок типа cp: cannot stat `01': No such file or directory. Если в значениях переменных $file или $target содержатся символы *, ?, [..] или (..), используемые в шаблонах подстановки имен файлов («wildmats»), то в случае существования файлов, удовлетворяющих шаблону, значения переменных будут преобразованы в имена этих файлов. Двойные кавычки решают эту проблему, если только "$file" не начинается с дефиса -, в этом случае cp думает, что вы пытаетесь указать ему еще одну опцию командной строки.

Один из способов обхода — вставить двойной дефис (--) между командой cp и её аргументами. Двойной дефис сообщит cp, что нужно прекратить поиск опций:

cp -- "$file" "$target"


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

Ещё один способ — убедиться, что названия файлов всегда начинаются с имени каталога (включая ./ для текущего). Например:

for i in ./*.mp3; do
    cp "$i" /target
    ...


Даже если у нас есть файл, название которого начинается с "-", механизм подстановки шаблонов гарантирует, что переменная будет содержать нечто вроде ./-foo.mp3, что абсолютно безопасно для использования вместе с cp.

3. [ $foo = «bar» ]



В этом примере кавычки расставлены неправильно: в bash нет необходимости заключать строковой литерал в кавычки; но вам обязательно следует закавычить переменную, если вы не уверены, что она не содержит пробелов или знаков подстановки (wildcards).

Этот код ошибочен по двум причинам:

1. Если переменная, используемая в условии [, не существует или пуста, строка

[ $foo = "bar" ]


будет воспринята как

[ = "bar" ]


что вызовет ошибку «unary operator expected». (Оператор "=" бинарный, а не унарный, поэтому команда [ будет в шоке от такого синтаксиса)
2. Если переменная содержит пробел внутри себя, она будет разбита на разные слова перед тем, как будет обработана командой [:
[ multiple words here = "bar" ]

Даже если лично вам кажется, что это нормально, такой синтаксис является ошибочным.

Правильно будет так:

[ "$foo" = bar ]       # уже близко!


Но этот вариант не будет работать, если $foo начинается с -.

В bash для решения этой проблемы может быть использовано ключевое слово [[, которое включает в себя и значительно расширяет старую команду test (также известную как [)

[[ $foo = bar ]]       # правильно!


Внутри [[ и ]] уже не нужно брать в кавычки названия переменных, поскольку переменные больше не разбиваются на слова и даже пустые переменные обрабатываются корректно. С другой стороны, даже если лишний раз взять их в кавычки, это ничему не повредит.

Возможно, вы видели код типа такого:

[ x"$foo" = xbar ]    # тоже правильно!


Хак x"$foo" требуется в коде, который должен работать в шеллах, не поддерживающих [[, потому что если $foo начинается с -, команда [ будет дезориентирована.

Если одна из частей выражения — константа, можно сделать так:
[ bar = "$foo" ]      # так тоже правильно!


Команду [ не волнует, что выражение справа от знака "=" начинается с -. Она просто использует это выражение, как строку. Только левая часть требует такого пристального внимания.

4. cd `dirname "$f"`



Пока что мы в основном говорим об одном и том же. Точно так же, как и с раскрытием значений переменных, результат подстановки команды подвергается разбиению на слова и раскрытию имен файлов (pathname expansion). Поэтому мы должны заключить команду в кавычки:

cd "`dirname "$f"`"


Что здесь не совсем очевидно, это последовательность кавычек. Программист на C мог бы предположить, что сгруппированы первая и вторая кавычки, а также третья и четвёртая. Однако в данном случае это не так. Bash рассматривает двойные кавычки внутри команды как первую пару, и наружные кавычки — как вторую.

Другими словами, парсер рассматривает обратные кавычки (`) как уровень вложенности, и кавычки внутри него отделены от внешних.

Такого же эффекта можно достичь, используя более предпочтительный синтаксис $():

cd "$(dirname "$f")"


Кавычки внутри $() сгруппированы.

5. [ "$foo" = bar && "$bar" = foo ]



Нельзя использовать && внутри «старой» команды test или её эквивалента [. Парсер bash'а видит && вне скобок и разбивает вашу команду на две, перед и после &&. Лучше используйте один из вариантов:

[ bar = "$foo" -a foo = "$bar" ]       # Правильно!
[ bar = "$foo" ] && [ foo = "$bar" ]   # Тоже правильно!
[[ $foo = bar && $bar = foo ]]         # Тоже правильно!


Обратите внимание, что мы поменяли местами константу и переменную внутри [ — по причинам, рассмотренным в предыдущем пункте.

То же самое относится и к ||. Используйте [[, или -o, или две команды [.

6. [[ $foo > 7 ]]


Если оператор > используется внутри [[ ]], он рассматривается как оператор сравнения строк, а не чисел. В некоторых случаях это может сработать, а может и не сработать (и это произойдёт как раз тогда, когда вы меньше всего будете этого ожидать). Если > находится внутри [ ], всё ещё хуже: в данном случае это перенаправление вывода из файлового дескриптора с указанным номером. В текущем каталоге появится пустой файл с названием 7, и команда test завершится с успехом, если только переменная $foo не пуста.

Поэтому операторы > и < для сравнения чисел внутри [ .. ] или [[ .. ]] использовать нельзя.

Если вы хотите сравнить два числа, используйте (( )):

((foo > 7))                             # Правильно!


Если вы пишете для Bourne Shell (sh), а не для bash, правильным способом является такой:

[ $foo -gt 7 ]                          # Тоже правильно!


Обратите внимание, что команда test ... -gt ... выдаст ошибку, если хотя бы один из её аргументов — не целое число. Поэтому уже не имеет значения, правильно ли расставлены кавычки: если переменная пустая, или содержит пробелы, или ее значение не является целым числом — в любом случае возникнет ошибка. Просто тщательно проверяйте значение переменной перед тем, как использовать её в команде test.

Двойные квадратные скобки также поддерживают такой синтаксис:

[[ $foo -gt 7 ]]                        # Тоже правильно!


7. count=0; grep foo bar | while read line; do ((count++)); done; echo «number of lines: $count»


На первый взгляд этот код выглядит нормально. Но на деле переменная $count останется неизменной после выхода из цикла, к большому удивлению bash-разработчика. Почему так происходит?

Каждая команда в конвейере выполняется в отдельной подоболочке (subshell), и изменения в переменной внутри подоболочки не влияют на значение этой переменной в родительском экземпляре оболочки (т.е. в скрипте, который вызвал этот код).

В данном случае цикл for является частью конвейера и выполняется в отдельной подоболочке со своей копией переменной $count, инизиализированной значением переменной $count из родительской оболочки: «0». Когда цикл заканчивается, использованная в цикле копия $count отбрасывается и команда echo показывает неизменённое начальное значение $count («0»).

Обойти это можно несколькими способами.

Можно выполнить цикл в своей подоболочке (слегка кривовато, но так проще и понятней и работает в sh):

# POSIX compatible
count=0
cat /etc/passwd | (
    while read line ; do
        count=$((count+1))
    done
    echo "total number of lines: $count"
)


Чтобы полностью избежать создания подоболочки, используйте перенаправление (в Bourne shell (sh) для перенаправления также создаётся subshell, поэтому будьте внимательны, такой трюк сработает только в bash):

# только для bash!
count=0
while read line ; do
    count=$(($count+1))
done < /etc/passwd
echo "total number of lines: $count"


Предыдущий способ работает только для файлов, но что делать, если нужно построчно обработать вывод команды? Используйте подстановку процессов:
while read LINE; do
    echo "-> $LINE"
done < <(grep PATH /etc/profile)


Ещё пара интересных способов разрешения проблемы с субшеллами обсуждается в Bash FAQ #24.

8. if [grep foo myfile]



Многих смущает практика ставить квадратные скобки после if и у новичков часто создаётся ложное впечатление, что [ является частью условного синтаксиса, так же, как скобки в условных конструкциях языка C.

Однако такое мнение — ошибка! Открывающая квадратная скобка ([) — это не часть синтаксиса, а команда, являющаяся эквивалентом команды test, лишь за тем исключением, что последним аргументом этой команды должна быть закрывающая скобка ].

Синтаксис if:

if COMMANDS
then
    COMMANDS
elif COMMANDS     # необязательно
then
    COMMANDS
else              # необязательно
    COMMANDS
fi


Как видите, в синтаксисе if нет никаких [ или [[!

Ещё раз, [ — это команда, которая принимает аргументы и выдаёт код возврата; как и все нормальные команды, она может выводить сообщения об ошибках, но, как правило, ничего не выдаёт в STDOUT.

if выполняет первый набор команд, и в зависимости от кода возврата последней команды из этого набора определяет, будет ли выполнен блок команд из секции «then» или же выполнение скрипта продолжится дальше.

Если вам необходимо принять решение в зависимости от вывода команды grep, вам не нужно заключать её в круглые, квадратные или фигурные скобки, обратные кавычки или любой другой синтаксический элемент. Просто напишите grep как команду после if:

if grep foo myfile > /dev/null; then
    ...
fi


Обратите внимание, что мы отбрасываем стандартный вывод grep: нам не нужен результат поиска, мы просто хотим знать, присутствует ли строка в файле. Если grep находит строку, он возвращает 0, и условие выполняется; в противном случае (строка в файле отсутствует) grep возвращает значение, отличное от 0. В GNU grep перенаправление >/dev/null можно заменить опцией -q, которая говорит grep'у, что ничего выводить не нужно.

9. if [bar="$foo"]



Как было объяснено в предыдущем параграфе, [ — это команда. Как и в случае любой другой команды, bash предполагает, что после команды следует пробел, затем первый аргумент, затем снова пробел, и т.д. Поэтому нельзя писать всё подряд без пробелов! Правильно вот так:

if [ bar = "$foo" ]


bar, =, "$foo" (после подстановки, но без разделения на слова) и ] являются аргументами команды [, поэтому между каждой парой аргументов обязательно должен присутствовать пробел, чтобы шелл мог определить, где какой аргумент начинается и заканчивается.

10. if [ [ a = b ] && [ c = d ] ]



Снова та же ошибка. [ — команда, а не синтаксический элемент между if и условием, и тем более не средство группировки. Вы не можете взять синтаксис C и переделать его в синтаксис bash простой заменой круглых скобок на квадратные.

Если вы хотите реализовать сложное условие, вот правильный способ:

if [ a = b ] && [ c = d ]


Заметьте, что здесь у нас две команды после if, объединённые оператором &&. Этот код эквивалентент такой команде:

if test a = b && test c = d


Если первая команда test возвращает значение false (любое ненулевое число), тело условия пропускается. Если она возвращает true, выполняется второе условие; если и оно возвращает true, то выполняется тело условия.

Продолжение следует.

Первая публикация этого перевода происходила на страницах моего блога.
Автор оригинала: Greg Wooledge
Владимир Бредников @bappoy
карма
65,7
рейтинг 0,0
Похожие публикации

Комментарии (25)

  • +6
    да, действительно полезное чтиво :)
    • 0
      Угу. По крайней мере здесь собраны вещи, которые не являются простым переводом man'а на русский (как часто бывает в подобных статьях).
  • +1
    по поводу «if grep foo myfile > /dev/null; then»

    у грепа есть ключик -q для этого ;)

    т.е. это будет выглядеть так:

    if grep -q foo myfile; then
    • +1
      собственно, об этом написано двумя строчками ниже
      • 0
        странно, я не заметил :(
        ну ладно))
  • +2
    на удивление хороший материал!
    • +2
      Вы знаете, что делать! ;)
  • +1
    Вообще не стоит пользоваться конструкцией типа RESULT=`cat file.txt`.
    Более читабелен и современен такой вариант RESULT=$(cat file.txt)
    • 0
      А какая разница? Ну кроме того, что кавычки `` всегда обозначают выполнимую внешнюю команду, а для конструкции $() придётся морщить мозг, пытаясь понять, а что это было.
  • 0
    Спасибо за полезный материал!
    Жаль, не все, придется читать оригинал :)
    • 0
      по ссылке внизу текста есть побольше — на следующей неделе запощу
    • +1
      ух ты, это Ваш первый комментарий на Хабре? Поздравляю :)
      • 0
        да, не cмог удержаться :)
        • 0
          Главное, не останавливайтесь на достигнутом.
  • 0
    В одной этой статье больше синтаксических правил, чем во всём языке Tcl. ;)

    Когда восстановится заряд поблагодарю за полезную информацию. Всегда долго думал над if без квадратных скобок в чужих скриптах.
  • 0
    Было весьма познавательно! Спасибо. Жду продолжения.
  • –2
    Вот еще один хороший аргумент в пользу отказа от использования shell-скриптов, по крайней мере в дистрибутивах.
    • +3
      Где?!
      • 0
        В тексте статьи.

        Написано же — в bash проблемы со «сложными» именами файлов (насколько я помню, вроде даже какие-то портированные на Винду Линуксовые проги отказываются работать в каталогах с пробелами. типа Program Files). надо потоянно извращаться, чтобы работали любые имена, и разработчик может легко об этом забыть, тем более что у многих в системе не используются имена с пробелами, и это может остаться незамеченным.

        Велика вероятность появления скриптов с ошибками (более того, уверен, что они есть, надо просто поискать).
        • 0
          Видите ли, лично Вас никто не заставляет писать скрипты именно на bash. Не нравится, как он работает под виндой с каталогами, содержащими пробелы в названиях — Бога ради, пользуйте Perl, Python, PowerShell, vbs, command.com или что там еще под нее бывает, вариантов масса. Еще больше вариантов в Unix-подобных системах. И для каждого из них можно составить подобный список типичных ошибок и подводных камней.

          Эта статья — для тех, кто хочет быстро написать скрипт для автоматизации работы и быть при этом уверенным в том, что все сделано правильно. Я сам, если возникают проблемы с bash'ем (с кавычками, например, там черт ногу сломит), которые не удаётся решить в течение 10 минут, все бросаю и переписываю на perl.
  • +2
    Существует еще такое решение первой проблемы:
    find. -name '*.mp3' -print0 | xargs -I{} -0 some_command {}

    Использование опции -print0 решает проблему всякой хрени в именах файлов ( пробелов и т.д.) путем использования нуля как символа конца строки. Она действует в связке с опцией -0 команды xargs, которая заставляет xargs считать ноль, а не пробел символом конца входной строки.
    • –3
      Лучшим решением первой проблемы является запрет на имена файлов с пробелами. Это меня бесило еще 6 лет назад на Windows, и продолжает бесить до сих пор на никсах (в основном из-за find'а)
  • 0
    Спасибо, очень полезно в связи с предстоящим погружением в эту среду :)
  • 0
    настоящая уличная магия :)
  • 0
    Полезная вещь. Почитаю как следует. Хотя я стараюсь обьходиться питоном, но баш все таки еще нужен

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