Ошибки программирования на Bash

https://habrahabr.ru/post/47706/

Качество скриптов, используемых для автоматизации и оптимизации работы системы, является залогом ее стабильности и долголетия, а также сохраняет время и нервы администратора этой системы. Несмотря на кажущуюся примитивность 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, будет рассматриваться как одно слово, и цикл пройдёт по каждому имени файла по одному разу. Внимательный читатель должен был заметить кавычки во второй строке вышеприведённого примера. Это плавно подводит нас к подвоху №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 останется неизменной после выхода из цикла. Почему так происходит? Каждая команда в конвейере выполняется в отдельной подоболочке (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, то выполняется тело условия.

11. cat file | sed s/foo/bar/ > file

Нельзя читать из файла и писать в него в одном и том же конвейере. В зависимости от того, как построен конвейер, файл может обнулиться (или оказаться усечённым до размера, равному объёму буфера, выделяемого операционной системой для конвейера), или неограниченно увеличиваться до тех пор, пока он не займёт всё доступное пространство на диске, или не достигнет ограничения на размер файла, заданного операционной системой или квотой, и т.д. Если вы хотите произвести изменение в файле, отличное от добавления данных в его конец, вы должны в какой-то промежуточный момент создать временный файл. Например (этот код работает во всех шеллах):

sed 's/foo/bar/g' file > tmpfile && mv tmpfile file

Следующий фрагмент будет работать только при использовании GNU sed 4.x и выше:

sed -i 's/foo/bar/g' file

Обратите внимание, что при этом тоже создаётся временный файл и затем происходит переименование — просто это делается незаметно. В BSD-версии sed необходимо обязательно указывать расширение, добавляемое к запасной копии файла. Если вы уверены в своем скрипте, можно указать нулевое расширение:

sed -i '' 's/foo/bar/g' file

Также можно воспользоваться perl 5.x, который, возможно, встречается чаще, чем sed 4.x:

perl -pi -e 's/foo/bar/g' file

Различные аспекты задачи массовой замены строк в куче файлов обсуждаются в Bash FAQ #21.

12. echo $foo

Эта относительно невинно выглядящая команда может привести к неприятным последствиям. Поскольку переменная $foo не заключена в кавычки, она будет не только разделена на слова, но и возможно содержащийся в ней шаблон будет преобразован в имена совпадающих с ним файлов. Из-за этого bash-программисты иногда ошибочно думают, что их переменные содержат неверные значения, тогда как с переменными всё в порядке — это команда echo отображает их согласно логике bash, что приводит к недоразумениям.

MSG="Please enter a file name of the form *.zip"

echo $MSG

Это сообщение разбивается на слова и все шаблоны, такие, как *.zip, раскрываются. Что подумают пользователи вашего скрипта, когда увидят фразу:

Please enter a file name of the form freenfss.zip lw35nfss.zip

Вот ещё пример:

VAR=*.zip       # VAR содержит звёздочку, точку и слово "zip"

echo "$VAR"     # выведет *.zip

echo $VAR       # выведет список файлов, чьи имена заканчиваются на .zip

На самом деле, команда echo вообще не может быть использована абсолютно безопасно. Если переменная содержит только два символа "-n", команда echo будет рассматривать их как опцию, а не как данные, которые нужно вывести на печать, и абсолютно ничего не выведет. Единственный надёжный способ напечатать значение переменной — воспользоваться командой printf:

printf "%s\n" "$foo".

13. $foo=bar

Нет, вы не можете создать переменную, поставив "$" в начале её названия. Это не Perl. Достаточно написать:

foo=bar

14. foo = bar

Нет, нельзя оставлять пробелы вокруг "=", присваивая значение переменной. Это не C. Когда вы пишете foo = bar, оболочка разбивает это на три слова, первое из которых, foo, воспринимается как название команды, а оставшиеся два — как её аргументы. По этой же причине нижеследующие выражения также неправильны:

foo= bar    # НЕПРАВИЛЬНО!

foo =bar    # НЕПРАВИЛЬНО!

$foo = bar  # АБСОЛЮТНО НЕПРАВИЛЬНО!

foo=bar     # Правильно.

15. echo <<EOF

Встроенные документы полезны для внедрения больших блоков текстовых данных в скрипт. Когда интерпретатор встречает подобную конструкцию, он направляет строки вплоть до указанного маркера (в данном случае — EOF) на входной поток команды. К сожалению, echo не принимает данные с STDIN.

# Неправильно:

echo <<EOF

Hello world

EOF

# Правильно:

cat <<EOF

Hello world

EOF

16. su -c 'some command'

В Linux этот синтаксис корректен и не вызовет ошибки. Проблема в том, что в некоторых системах (например, FreeBSD или Solaris) аргумент -c команды su имеет совершенно другое назначение. В частности, в FreeBSD ключ -c указывает класс, ограничения которого применяются при выполнении команды, а аргументы шелла должны указываться после имени целевого пользователя. Если имя пользователя отсутствует, опция -c будет относиться к команде su, а не к новому шеллу. Поэтому рекомендуется всегда указывать имя целевого пользователя, вне зависимости от системы (кто знает, на каких платформах будут выполняться ваши скрипты...):

su root -c 'some command' # Правильно.

17. cd /foo; bar

Если не проверить результат выполнения cd, в случае ошибки команда bar может выполниться не в том каталоге, где предполагал разработчик. Это может привести к катастрофе, если bar содержит что-то вроде rm *. Поэтому всегда нужно проверять код возврата команды «cd». Простейший способ:

cd /foo && bar

Если за cd следует больше одной команды, можно написать так:

cd /foo || exit 1

bar

baz

bat ... # Много команд.

cd сообщит об ошибке смены каталога сообщением в stderr вида bash: cd: /foo: No such file or directory. Если вы хотите вывести своё сообщение об ошибке в stdout, следует использовать группировку команд:

cd /net || { echo "Can't read /net.  Make sure you've logged in to the Samba network, and try again."; exit 1; }

do_stuff

more_stuff

Обратите внимание на пробел между { и echo, а также на точку с запятой перед закрывающей }. Некоторые добавляют в начало скрипта команду set -e, чтобы их скрипты прерывались после каждой команды, вернувшей ненулевое значение, но этот трюк нужно использовать с большой осторожностью, поскольку многие распространённые команды могут возвращать ненулевое значение в качестве простого предупреждения об ошибке (warning), и совершенно необязательно рассматривать такие ошибки как критические.

Кстати, если вы много работаете с директориями в bash-скрипте, перечитайте man bash в местах, относящихся к командам pushd, popd и dirs. Возможно, весь ваш код, напичканный cd и pwd, просто не нужен :). Вернёмся к нашим баранам. Сравните этот фрагмент:

find ... -type d | while read subdir; do

    cd "$subdir" && whatever && ... && cd -

done

с этим:

find ... -type d | while read subdir; do

    (cd "$subdir" && whatever && ...)

done

Принудительный вызов подоболочки заставляет cd и последующие команды выполняться в subshell'е; в следующей итерации цикла мы вернёмся в начальное местонахождение вне зависимости от того, успешной ли была смена директории или же она завершилась с ошибкой. Нам не нужно возвращаться вручную. 

Кроме того, предпоследний пример содержит ещё одну ошибку: если одна из команд whatever провалится, мы можем не вернуться обратно в начальный каталог. Чтобы исправить это без использования субшелла, в конце каждой итерации придётся делать что-то вроде cd "$ORIGINAL_DIR", а это добавит ещё немного путаницы в ваши скрипты.

18. [ bar == "$foo" ]

Оператор == не является аргументом команды [. Используйте вместо него = или замените [ ключевым словом [[:

[ bar = "$foo" ] && echo yes

[[ bar == $foo ]] && echo yes

19. for i in {1..10}; do ./something &; done

Нельзя помещать точку с запятой ";" сразу же после &. Просто удалите этот лишний символ:

 for i in {1..10}; do ./something & done

Символ & сам по себе является признаком конца команды, так же, как ";" и перевод строки. Нельзя ставить их один за другим.

20. cmd1 && cmd2 || cmd3

Многие предпочитают использовать && и || в качестве сокращения для if ... then ... else ... fi. В некоторых случаях это абсолютно безопасно:

[[ -s $errorlog ]] && echo "Uh oh, there were some errors." || echo "Successful."

Однако в общем случае эта конструкция не может служить полным эквивалентом if ... fi, потому что команда cmd2 перед && также может генерировать код возврата, и если этот код не 0, будет выполнена команда, следующая за ||. Простой пример, способный многих привести в состояние ступора:

i=0

true && ((i++)) || ((i--))

echo $i   # выведет 0

Что здесь произошло? По идее, переменная i должна принять значение 1, но в конце скрипта она содержит 0. То есть последовательно выполняются обе команды i++ и i--. Команда ((i++)) возвращает число, являющееся результатом выполнения выражения в скобках в стиле C. Значение этого выражения — 0 (начальное значение i), но в C выражение с целочисленным значением 0 рассматривается как false. Поэтому выражение ((i++)), где i равно 0, возвращает 1 (false) и выполняется команда ((i--)). Этого бы не случилось, если бы мы использовали оператор преинкремента, поскольку в данном случае код возврата ++i — true:

i=0

true && (( ++i )) || (( --i ))

echo $i    # выводит 1

Но нам всего лишь повезло и наш код работает исключительно по «случайному» стечению обстоятельств. Поэтому нельзя полагаться на x && y || z, если есть малейший шанс, что y вернёт false (последний фрагмент кода будет выполнен с ошибкой, если i будет равно -1 вместо 0) Если вам нужна безопасность, или вы сомневаетесь в механизмах, которые заставляют ваш код работать, или вы ничего не поняли в предыдущих абзацах, лучше не ленитесь и пишите if ... fi в ваших скриптах:

i=0

if true; then

    ((i++))

else

    ((i--))

fi

echo $i   # выведет 1. 

Bourne shell это тоже касается:

# Выполняются оба блока команд:

$ true && { echo true; false; } || { echo false; true; }

true

false

21. Касательно UTF-8 и BOM (Byte-Order Mark, метка порядка байтов)

В общем: в Unix тексты в кодировке UTF-8 не используют метки порядка байтов. Кодировка текста определяется по локали, mime-типу файла, или по каким-то другим метаданным. Хотя наличие BOM не испортит UTF-8 документ в плане его читаемости человеком, могут возникнуть проблемы с автоматической интерпретацией таких файлов в качестве скриптов, исходных кодов, файлов конфигурации и т.д. Файлы, начинающиеся с BOM, должны рассматриваться как чужеродные, так же как и файлы с DOS'овскими переносами строк.

В шелл-скриптах: «Там, где UTF-8 может прозрачно использоватся в 8-битных окружениях, BOM будет пересекаться с любым протоколом или форматом файлов, предполагающим наличие символов ASCII в начале потока, например, #! в начале шелл-скриптов Unix» http://unicode.org/faq/utf_bom.html#bom5

22. echo "Hello World!"

Проблема в том, что в интерактивной оболочке Bash эта команда вызовет ошибку:

bash: !": event not found

Это происходит потому, что при установках по умолчанию Bash выполняет подстановку истории команд в стиле csh с использованием восклицательного знака. В скриптах такой проблемы нет, только в интерактивной оболочке. Очевидное решение здесь не работает:

$ echo "hi\!"

hi\!

Можно заключить эту строку в одинарные кавычки:

echo 'Hello World!'

Но самое подходящее решение здесь — временно выключить параметр histexpand. Это можно сделать командой set +H или set +o histexpand:

set +H

echo "Hello World!"

Почему же тогда всегда не пользоваться одиночными кавычками? Представьте, что вы хотите получить информацию об mp3-файлах:

mp3info -t "Don't Let It Show" ...

mp3info -t "Ah! Leah!" ...

Одинарные кавычки здесь не подходят, поскольку названия песен содержат апострофы в названиях, а использование двойных кавычек приведёт к проблеме с подстановкой истории команд (а если бы в именах файлов ещё и двойные ковычки содержались, получилось бы вообще черте что). Поскольку лично я (Greg Wooledge, автор текста) никогда не использую подстановку истории команд, я просто поместил команду set +H в свой .bashrc. Но это вопрос привычки и каждый решает для себя сам.

23. for arg in $*

В Bash'е, так же, как и в других оболочках семейства Bourne shell, есть специальный синтаксис для работы с позиционными параметрами по очереди, но $* и $@ не совсем то, что вам нужно: после подстановки параметров они становятся списком слов, переданных в аргументах, а не списком параметров по отдельности. Вот правильный синтаксис:

for arg in "$@"

Или просто:

for arg

for arg соответствует for arg in "$@". Заключенная в двойные кавычки переменная "$@" — это специальная уличная магия, благодаря которой каждый аргумент командной строки заключается в двойные кавычки, так что он выглядит как отдельное слово. Другими словами, "$@" преобразуется в список "$1" "$2" "$3" и т.д. Этот трюк подойдёт в большинстве случаев. Рассмотрим пример:

#!/bin/bash

# неправильно

for x in $*; do

echo "parameter: '$x'"

done

Этот код напечатает:

$ ./myscript 'arg 1' arg2 arg3

parameter: 'arg'

parameter: '1'

parameter: 'arg2'

parameter: 'arg3'

Вот как это должно выглядеть:

#!/bin/bash

# правильно!

for x in "$@"; do

    echo "parameter: '$x'"

done

$ ./myscript 'arg 1' arg2 arg3

parameter: 'arg 1'

parameter: 'arg2'

parameter: 'arg3'

24. function foo()

В некоторых шеллах это работает, но не во всех. Никогда не комбинируйте ключевое слово function со скобками (), определяя функцию. Некоторые версии bash позволяют одновременно использовать и function, и (), но ни в одной другой оболочке так делать нельзя. Некоторые интерпретаторы, правда, воспримут function foo, но для максимальной совместимости лучше использовать:

foo() {

 ...

}

25. echo "~"

Замена тильды (tilde expansion) происходит только когда символ ~ не окружён кавычками. В этом примере echo выведет ~ в stdout, вместо того, чтобы вывести пользовательский домашний каталог. Экранирование переменных с путями, которые должны быть выражены относительно домашнего каталога, должно производиться с использованием $HOME вместо ~.

"~/dir with spaces"       #  "~/dir with spaces"

~"/dir with spaces"       # "~/dir with spaces"

~/"dir with spaces"       # "/home/my photos/dir with spaces"

"$HOME/dir with spaces"   # "/home/my photos/dir with spaces"

26. local varname=$(command)

Определяя локальную переменную в функции, local сама работает как команда. Иногда это может непонятным образом взаимодействовать с остатком строки. Например, если в следующей команде вы хотите получить код возврата ($?) подставленной команды, вы его не получите: код возврата команды local его перекрывает. Поэтому эти команды лучше разделять:

local varname

varname=$(command)

rc=$?

Фигурные скобки

http://rus-linux.net/lib.php?name=/MyLDP/consol/brace-ru.html

Что означают фигурные скобки ?

Фигурные скобки {по-английски - brace} это один из условных знаков, помогающих сократить количество писанины в командной строке. Формально они входят в число семи expansions (расширение, раскрытие), применяемых в командной строке шелла bash. По-русски их лучше всего назвать сокращениями. Например: всем известная тильда (~), будучи напечатана в командной строке, раскроется в путь к нашему домашнему каталогу:

Раскрытие фигурных скобок

Допустим, что нам нужно создать для фотоальбома двенадцать каталогов (по числу месяцев) 2009 года. Мы можем поступить так:

$ mkdir фото_01_2009 фото_02_2009 ... фото_12_2009

(вместо троеточия впишем имена всех промежуточных каталогов). А можем привлечь на помощь сокращение - фигурные скобки:

$ mkdir фото_{01,02,03,04,05,06,07,08,09,10,11,12}_2009

Проделав этот опыт убеждаемся, что в рабочей директории появилось 12 новых каталогов. Чтобы они нам в дальнейшем не мешали, удалим их:

$ rm -R фото_{01,02,03,04,05,06,07,08,09,10,11,12}_2009

Однако интуиция подсказывает, что должен существовать и более короткий путь, и этот путь, конечно, есть:

$ mkdir фото_{01..12}_2009

А для более сложных сочетаний даже:

$ mkdir фото_{{01..05},07,{09..12}}_2009

Это, сами понимаете, для выборочного создания директорий. Чтобы закончить с этим примером, отметим, что в выражении фото_{01,02,03,04,05,06,07,08,09,10,11,12}_2009, часть выражения фото_ будет называться префиксом, а _2009 называется суффиксом (или окончанием). Вот еще пример применения фигурных скобок:

Нужно изменить права доступа к нескольким файлам: old, current и new, находящимся в одной директории:

$ chmod u+x /путь_к_директории/{old,current,new}

Мы применили фигурные скобки, чтобы не писать имена и пути (path) всех трех файлов полностью.

Раскрытие скобок

Существует несколько правил, которые соблюдаются при раскрывании фигурных скобок:

Правило 1. 

Внутри фигурных скобок не должно быть пробелов, так как шелл воспринимает пробел как разделитель. Строго говоря, кроме пробела существуют и другие разделители, например точка с запятой, но мы сейчас касаться их не будем, чтобы не отклониться в сторону. Например, мы можем создать файлы пес.txt и кот.txt командой:

$ touch {пес.txt,кот.txt}

И они будут благополучно созданы.

$ ls

кот.txt

пес.txt 

Но, стоит внутрь фигурных скобок проникнуть пробелу, как начнется нечто несуразное:

$ touch {пес.txt ,кот.txt}

Проверим, что вышло:

$ ls

{пес.txt

,кот.txt}

Мы получили два файла, но с совершенно невообразимыми именами! Однако использовать в фигурных скобках пробелы можно, либо заключив их в одинарные или двойные кавычки, либо экранировав их с помощью символа \.

echo {test1,test2}\ :{\ A," B",' C'}

выведет:

$ ~ echo {test1,test2}\ :{\ A," B",' C'}

test1 : A test1 : B test1 : C test2 : A test2 : B test2 : C

$ ~

Правило 2. 

При раскрытии фигурных скобок никакой сортировки объектов не происходит, и они интерпретируются в том же порядке, в каком указаны внутри фигурных скобок. Имеется в виду, конечно, не сортировка файлов в алфавитном или ином порядке; команда ls, при помощи которой мы просматриваем содержимое директорий, автоматически сортирует файлы по алфавиту. Также поступает и любой менеджер файлов, захоти мы просмотреть рабочую директория в графическом интерфейсе. Например, команда touch создает файлы в алфавитном порядке, независимо от того, как мы разместим их в фигурных скобках:

$ touch file{d,c,b}.txt

Посмотрим:

$ ls

fileb.txt  filec.txt  filed.txt

Отключим сортировку в команде ls:

$ ls -U

fileb.txt  filec.txt  filed.txt

Все равно, файлы создаются в том же порядке. Правило 2 говорит о другой сортировке - о том, что при раскрытии фигурных скобок, действия над объектами выполняются в том же порядке, в каком они записаны внутри фигурных скобок, и считывание происходит, как и положено, слева направо (в порядке чтения). Вот пример:

$ echo {о,антре,с,}кот

окот антрекот скот кот 

Порядок подстановки сохранен, и получившиеся слова сохраняют порядок, в котором их части находились внутри фигурных скобок. Есть случаи, когда это свойство фигурных скобок приобретает важное значение. Скажем, мы решили отредактировать файл /etc/X11/xorg.conf. Перед этим обычно создают его резервную копию. Мы воспользуемся для этого фигурными скобками. Только пойдем на подстраховку - чтобы не проводить обучение с реальным файлом /etc/X11/xorg.conf, что может закончиться печально, мы создадим в домашней директории папку "Опыт":

$ mkdir Опыт

и сразу перейдем в нее:

$ cd Опыт

Проверим, все ли в порядке:

$ pwd

/home/ya/Desktop/Опыт

Теперь, в этой папке, мы можем создавать, изменять и уничтожать любые файлы, и ничего нам за это не будет. Итак, создадим файл xorg.conf:

[Опыт]$ touch xorg.conf

Проверим:

[Опыт]$ ls

xorg.conf

Теперь создадим его резервную копию, применяя фигурные скобки:

[Опыт]$ cp xorg.conf{,.bak}

Проверим:

[Опыт]$ ls

xorg.conf  xorg.conf.bak

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

[Опыт]$ cp xorg.conf{.bak,}

cp: переписать `xorg.conf'? Y

Команда cp запрашивает подтверждения, мы нажимаем ENTER, и дело сделано: файл xorg.conf переписан файлом xorg.conf.bak. Нужно только не забывать, что шелл интерпретирует команду:

$ cp xorg.conf{.bak,}   как    $ cp xorg.conf.bak xorg.conf.

Поэтому порядок объектов внутри фигурных скобок чрезвычайно важен.

Правило 3. 

При раскрытии фигурных скобок шелл рассматривает все символы внутри фигурных скобок как простые символы, а не как метасимволы или символы регулярных выражений. Поэтому, хотя команда

$ rm file*

Удалит из текущей директории все файлы типа file1, file2, fileN, file_file и подобные, но команда :

$ rm ./file{*,1}

удалит только два файла file* и file1, то есть астериск (*) будет интерпретирован как простая звездочка.

Правило 4. 

Если нужно поместить внутри фигурных скобок выражения, содержащие фигурные скобки, или запятые, то необходимо экранировать эти символы обратным слэшем (/), а если нужно ввести сам обратный слэш, то его экранируют вторым обратным слэшем:

$ echo Например:{comma-\,,brace-\{,backslash-\\}

Резюме:   Фигурные скобки, могут здорово помочь при работе в командной строке.

Квадратные скобки

http://www.bash-scripting.ru/abs/chunks/ch07.html

https://www.ibm.com/developerworks/ru/library/l-bash-test/l-bash-test-pdf.pdf

Пара квадратных скобок [ ], в которую заключен список символов, заставляет оболочку искать имена файлов, содержащие отдельные символы.

Конструкция [[ ]] это расширенный вариант конструкция с одинарными квадратными скобками, в двойных квадратных скобках также проверяется истинность, заключенного в данную конструкцию, выражения, но этот вариант более предпочтителен, поскольку позволяет избежать некоторых логических ошибок. Например в конструкции с двойными квадратными скобками, допустимо использовать операторы &&, ||, < и >, в то время как в одинарных скобках они приведут к ошибке.

При использовании с условным оператором if, наличие квадратных скобок, как одинарных так и двойных, не обязательно.

Конструкция [[ ]] более универсальна, по сравнению с [ ]. Этот расширенный вариант команды test перекочевал в Bash из ksh88. Внутри этой конструкции не производится никакой дополнительной интерпретации имен файлов и не производится разбиение аргументов на отдельные слова, но допускается подстановка параметров и команд.

ile=/etc/passwd

if [[ -e $file ]]

then

  echo "Файл паролей найден."

fi

Двойные круглые скобки

Между двойными круглыми скобками, вычисляется целочисленное арифметическое выражение. Кроме того двойные скобки позволяют работать с переменными в стиле языка C.

Синоним встроенной команды let (используется в случае, если вложенное значение имеет знак равенства)

\ — знак продолжения команды

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