При написании сценариев на Bash не только опытные программисты, но и новички в области командного интерпретатора Bash сталкиваются с работой со строками. Наиболее часто это необходимо при считывании команд, вводимых пользователем в качестве аргументов для исполняемого сценария, а также при обработке текстовых файлов. И один из необходимых приёмов в таком случае — это сравнение строк.
В данной статье будет рассмотрено сравнение строк Bash, а также некоторые нюансы по использованию операций сравнения и решению часто встречающихся ошибок.
Сравнение строк Bash
Данные операции позволяют определить, являются ли сравниваемые строки одинаковыми:
- = - равно, например if [ "$x" = "$y" ]
- == - синоним оператора "=", например if [ "$x" == "$y" ]
- != - не равно, например if [ "$x" != "$y" ]
Пример:
#!/bin/bash
testuser=anton
if [ $USER = $testuser ]
then
echo "Добро пожаловать, $testuser"
fi
Результат работы сценария:
При проверке на равенство с помощью команды test (синоним квадратным скобкам [ ]) учитываются все пунктуационные знаки и различия в регистре букв сравниваемых строк.
Некоторые особенности сравнения строк с шаблонами:
# возвращает истину, если строка, содержащаяся в $x, начинается с символа "y"
[[ $x == y* ]]
# возвращает истину, если строка из $x равна конкретно двум символам "y*"
[[ $x == "y*" ]]
# возвращает истину, если $x содержит название файла, содержащегося в текущем каталоге, которое начинается с "y"
[ $x == y* ]
# возвращает истину, если строка $x равна двум символам "y*"
[ "$x" == "y*" ]
Например проверка строки bash на то, начинается ли она с символа y:
#!/bin/bash
x=yandex
[[ $x == y* ]]
echo $?
Результат выполнения кода:
Сценарий вывел 0 (ноль), так как мы потребовали вывести код ошибки последней выполненной инструкции. А код 0 означает, что сценарий выполнился без ошибок. И действительно — переменная $x содержит строку yandex, которая начинается с символа "y". В противном случае может писаться "1". Это довольно удобный способ отладки сценариев.
Сравнение строк по алфавиту на Bash
Задача усложняется при попытке определить, является ли строка предшественницей другой строки в последовательности сортировки по возрастанию. Люди, пишущие сценарии на языке командного интерпретатора bash, нередко сталкиваются с двумя проблемами, касающимися операций "больше" и "меньше" относительно сравнения строк Linux, у которых достаточно простые решения:
Во-первых, символы "больше" и "меньше" нужно экранировать, добавив перед ними обратный слэш (\), потому что в противном случае в командном интерпретаторе они будут расцениваться как символы перенаправления, а строки — как имена файлов. Это один из тех случаев, когда отследить ошибку достаточно сложно.
Пример:
#!/bin/bash
# неправильное использование операторов сравнения строк
val1=baseball
val2=hockey
if [ $val1 > $val2 ]
then
echo "$val1 больше, чем $val2"
else
echo "$val1 меньше, чем $val2"
fi
Что получится, если сравнить строки bash:
Как видно, один лишь символ "больше" в своём непосредственном виде привёл к неправильным результатам, хотя и не было сформировано никаких ошибок. В данном случае этот символ привёл к перенаправлению потока вывода, поэтому никаких синтаксических ошибок не было обнаружено и, как результат, был создан файл с именем hockey:
Для устранения этой ошибки нужно экранировать символ ">", чтобы условие выглядело следующим образом:
...
if [ $val1 \> $val2 ]
...
Тогда результат работы программы будет правильным:
Во-вторых, упорядочиваемые с помощью операторов "больше" и "меньше" строки располагаются иначе, чем это происходит с командой sort. Здесь проблемы сложнее поддаются распознаванию, и с ними вообще можно не столкнуться, если при сравнении не будет учитываться регистр букв. В команде sort и test сравнение происходит по разному:
#!/bin/bash
val1=Testing
val2=testing
if [ $val1 \> $val2 ]
then
echo "$val1 больше, чем $val2"
else
echo "$val1 меньше, чем $val2"
fi
Результат работы кода:
В команде test строки с прописными буквами вначале будут предшествовать строкам со строчными буквами. Но если эти же данные записать в файл, к которому потом применить команду sort, то строки со строчными буквами будут идти раньше:
Разница их работы заключается в том, что в test для определения порядка сортировки за основу взято расположение символов по таблице ASCII. В sort же используется порядок сортировки, указанный для параметров языка региональных установок.
Проверка строки на пустое значение
Сравнение с помощью операторов -z и -n применяется для определения наличия содержимого в переменной. Таким образом, вы можете найти пустые строки bash. Пример:
#!/bin/bash
val1=testing
val2=''
# проверяет, не пустая ли строка
if [ -n $val1 ]
then
echo "Строка '$val1' не пустая"
else
echo "Строка '$val1' пустая"
fi
# проверяет, пустая ли строка
if [ -z $val2 ]
then
echo "Строка '$val2' пустая"
else
echo "Строка '$val2' не пустая"
fi
if [ -z $val3 ]
then
echo "Строка '$val3' пустая"
else
echo "Строка '$val3' не пустая"
fi
Результат работы кода:
В этом примере создаются две строковые переменные — val1 и val2. Операция -n определяет, имеет ли переменная val1 ненулевую длину, а -z проверяет val2 и val3 на нулевую. Примечательно то, что последняя не была определена до момента сравнения, но интерпретатор считает, что её длина всё же равна нулю. Такой нюанс следует учитывать при различных проверках сценариев. И, если нет уверенности в том, какое значение содержится в переменной и задано ли оно вообще, стоит проверить её с помощью оператора -n или -z и лишь затем использовать по назначению.
Стоит обратить внимание и на функцию -n. Если ей для проверки будет передана необъявленная или пустая переменная, будет возвращена истина, а не ложь. Для таких случаев следует заключать проверяемую строку (переменную) в двойные кавычки, чтобы выглядело это так:
...
if [ -n "$val1" ]
...
Выводы
В представленных операциях сравнения строк Bash есть определённые нюансы, которые стоит понять для предотвращения ошибок работы сценариев. Но таких ситуаций на практике встречает много, поэтому запомнить все (и тем более, описать) не получится.
При сравнении строк в виде переменных их можно заключать в кавычки практически всегда, так как это считается правилом хорошего тона, а заодно и страхует от семантических ошибок.
