2013-03-22 2 views
4

Я хочу решить, нужно ли всегда пропустить кавычки для переменных, появляющихся с тестом Bash [[. Я интерпретирую страницу man, чтобы сказать, что это допустимо сделать без какой-либо потери правильности.Bash [[тесты, цитирующие переменные


Я придумал этот упрощенный «тест», чтобы проверить свое мышление и «ожидаемое поведение», но он не может доказать, абсолютно ничего, посмотри на него:

x='1 == 2 &&'; if [[ $x == '1 == 2 &&' ]]; then echo yes; else echo no; fi 

Примечание Я не пишу это как таковой:

x='1 == 2 &&'; if [[ "$x" == '1 == 2 &&' ]]; then echo yes; else echo no; fi 

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


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

Я пытаюсь узнать Bash, и я пытаюсь сделать это собирание хорошие привычки, хороший стиль и правильность ..

+5

Одно предостережение: На правой стороне == и =, если он не котируется он рассматривается как образец, а не строки!. Итак, если 'x =" Now - это '' и 'y =" [nN] ow * "', тогда '[[$ x ==" $ y "]]' false, тогда как '[[$ x == $ y] ] 'истинно. Это может вас укусить в какой-то момент. – William

+0

Отличная точка! Благодаря!! Я имел в виду только левую сторону, хотя .. (я должен был указать это). Был рад узнать ваше понимание, хотя .. – Robottinosino

ответ

5

Главное, помнить о том, что котировки и избежать в шаблонов, соответствующих контекстах всегда вызывают их содержимое, чтобы стать буквальным. Цитирование на левой стороне == в пределах [[ никогда не требуется, только правая сторона интерпретируется как пат Эрн. Котировка с правой стороны необходима, если вы хотите иметь буквальное совпадение и избегать интерпретации метасимволов шаблона внутри переменной.

Иными словами, [ "$x" = "$x" ] и [[ $x == "$x" ]] в основном эквивалентны, и, конечно же, в Bash последнее должно быть предпочтительным.

Один быстрый совет: думайте о операторов в [[ ]] соединения COMAND как та же грамматика мудр, как и другие операторы управления такие как elif, do, ;; и ;;& (хотя технически в руководстве они» re в их собственной категории). Они действительно являются разделителями секций сложной команды, и именно так они достигают, казалось бы, магических свойств, таких как способность к короткозамкнутым расширениям. Это должно помочь прояснить большую часть поведения [[ и почему оно отличается от, например, арифметические операторы, которые не такие.

Другие примеры: http://mywiki.wooledge.org/BashFAQ/031#Theory

+0

Ваш вход всегда так ценится! Почему «последнее» было бы предпочтительнее? Для _use_ функции, что она есть? Я не вижу, как цитирование левой стороны «бесполезно» может повредить. Есть ли сценарий, в котором это было бы? – Robottinosino

+0

@Robottinosino Не то, что я знаю. Поскольку котировки никогда не требуются в этом контексте, не считая их, этот факт становится очевидным. Если вы используете их случайным образом или даже избыточно все время, гораздо легче запутаться, потому что люди будут видеть примеры, которые цитируются в некоторых местах, а не в других. Есть несколько мест, где вы действительно не хотите указывать по разным причинам. Если это случайное цитирование, где необязательно, неясно, в каких случаях это необязательно и в котором они опущены для реального эффекта. Иногда явное средство позволяет постоянно говорить о неявных вещах. – ormaaj

+0

Я не убежден в этом: «Иногда явное средство, позволяющее беспрепятственно выполнять неявные вещи», но я собираюсь принять ваш ответ в большей степени на основе уважения, которое у меня есть для вашего опыта и вашего общая полезность, которая действительно мотивирует. – Robottinosino

3

Нет, вы не должны войти в привычку всегда опуская кавычки, даже если они появляются в пределах [[ тестов. Bash известен сжигая людей для ухода от цитаты :-)

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

Рассмотрим это выражение:

if [[ "$INT" =~ ^-?[0-9]+$ ]]; then

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

Во всяком случае, это мое мнение, как парень, который получил королевскую подсоединенные шланги на руку Bash, потому что я не смог поставить " " вокруг чего-то, что в них нуждается: '(

Мой Баш друг хакерство однажды сказал , «использование приводит обильно в Bash.» Этот совет служил мне хорошо.

+2

Явный лучше, чем неявный, как и старый адажио, вдохновленный Python. Это то, что я всегда кодировал, согласно моему оригинальному сообщению. Поэтому я ** соглашаюсь с вами. Вы знаете, иногда люди расстраиваются даже из-за ** UUOC **, поэтому .. вы не можете угодить всем .. – Robottinosino

+1

Implicit лучше, чем явный для меня. У Bash много контекстно-зависимых подробностей. Очень необходимо знать точные правила. Если я вижу какой-то потенциально избыточный синтаксис, мне жаль, что я должен спросить себя, знает ли кодер, что они делают, когда они его там помещают. Поскольку сложный скрипт может зависеть от небольших деталей, по крайней мере, когда я пишу вещи, это помогает понять, что я поместил там какой-то синтаксис. Лучший стиль, вероятно, зависит от вашего уровня опыта. – ormaaj

+1

@ormaaj: Я в основном согласен, но в контексте bash я склонен думать о том, чтобы помещать вещи в двойные кавычки в качестве значения по умолчанию, и все, что * не * двойным кавычками, заставит меня остановиться и подумать о том, есть ли причина, и знал ли кодер, что они делают ... Таким образом, по сути, те же рассуждения приводят меня к противоположному выводу в этом случае. –

Смежные вопросы