Не понял про двухфакторную авторизацию, что такое 'коды фишатся' и почему этого нет при использовании аппаратного токена? — от слова фишинг? железные токены от этого не защищают.
Если что самые надежные — взаимодействия на базе цифровых подписей, сайт просит дать подпись к уникальному сообщению, содержащему описание операции, а пользователь его подписывает своим приватным ключом.
Так сложилось исторически. Многие вещи — наследие ещё более старых shell'ов. В случае примера выше [ является либо внешней программой, либо builtin'ом. И в том, и в другом случае пробел обязателен. А, например, арифметика вида $((a+1)) не требует пробелов, т. к. является частью синтаксических конструкций баша, и явно описана в грамматике в отличии от builtin'ов, которые сначала парсятся как generic конструкция и потому требуют разделения пробелами аргументов.
Да уж баш он такой баш. Я с ним исключительно на вы, т.к. потребность в написании скриптов возникает редко и каждый раз думаешь: а нужен тут пробел, кавычки и т.д.
Из гайда для меня самое ценное: shellcheck.net. Раньше не знал про такой ресурс. Так что спасибо.
Он, шелл (не надо говорить баш, это плохой тон), напротив, весьма согласован и логичен. Нужно лишь уяснить, что каждая строчка скрипта (кроме определений функций и управляющих конструкций) — это тупо команда + её аргументы. В этом свете сразу становятся понятными и требования пробелов в одном контексте, и запрещение их в другом, например, при присваивании переменной значения (ср. foo=bar с попыткой исполнения команды foo с параметрами = и bar).
[ изначально был программой, а не внутренней конструкцией языка, и все ифы, вайлы, форы... Зачем я это пишу? В man sh(1) всё отлично изложено.
На самом деле, именно что надо.
Bash даже в режиме эмуляции sh страдает башизмами.
Равно как и ZSH даже в режиме эмуляции bash, sh и других позволяет кучу вольностей.
Поэтому когда идёт речь о синтаксисе и его работоспособности — надо называть шелл по имени.
Это вы знаете о тонкостях эмуляции sh и слово «башизмы», вам можно. :-) Большинство же пишет шелл-скрипты, называя их баш-скриптами, просто потому, что других шеллов не знает (я чуть ниже об этом писал, в т.ч. почему это плохо).
Засомневался и специально проверил: нет проблем, ни при пустой, ни при неопределённой переменной. Во всяком случае, так в bash 4.3.30. Но я не силён в теме переносимости скриптов между шеллами/версиями шеллов, возможно вы и правы.
За советы типа «используйте [[, а не [» надо давать по рукам. Такой код не выполнится в стандартных реализациях sh(1), например в *BSD, а тащить каждый раз баш не хочется. Ну и [ — встроенная команда практически в любом современном шелле, так что это не аргумент.
Я заметил; нет, не странно. 99% баш-скриптов на самом деле каких-то действительно полезных фишек баша не используют (типа массивов, например, или улучшенного parameter expansion) и являются по сути обычными шелл-скриптами с непереносимыми конструкциями (навроде той же [[ -a ... вместо [ -e ... или == вместо =).
Не стоит приучать себя писать баш-скрипты: ни баш, ни [[ не стандартизованы, в отличие от POSIX shell и test ([). Переносимость — великая вещь. Пишите shell-скрипты, и старайтесь проверять их работу на нескольких разных реализациях *nix.
Комментарии 30
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.