Представь что у тебя есть переменная:

f="My Documents/file.txt"

И в скрипте мы делаем так:

cd $(dirname "$f")

Это ошибочный вариант, бэд мать его практика.

Команда cd $(dirname "$f") должна вернуть путь к папке, где лежит файл.
ㅤ
НО! Результат этой команды разбивается на части, если в нём есть пробелы.

Например:

dirname "My Documents/file.txt"

Выдаст: My Documents

А если так:

cd My Documents

Логично, получаем ошибку:

cd: No such file or directory: My

Bash думает что это два отдельных слова, а не один путь.

➡️ Бест-практика

cd -P -- "$(dirname -- "$f")"

1. Кавычки защищают результат команды от разбиения.
2. И cd получит целый путь, даже если в нём есть пробелы.

Как работают кавычки

- Когда Bash видит $(...), он воспринимает это как отдельную область, некий «уровень».

- Кавычки внутри $(...) работают только внутри.

- Кавычки снаружи не объединяются с внутренними.

Наглядно, можно представить так:

cd "$( dirname "$f" )"

Внутренние кавычки "$f" защищают переменную f

Внешние кавычки "" защищают результат dirname "$f"

Теперь даже если переменная будет содержать пробелы команда не разобьётся на части.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Вот те на!

if [ false ]; then echo "HELP"; fi

Большинство думает, что [ — это часть команды if как скобки в других языках программирования. Но нихуя!
ㅤ
В Bash if просто запускает команду. Команда [ ... ] — это обычный бинарник, аналогично команде test, а не специальный синтаксис.

Скобка ] нужна только для красоты и завершения команды [.

Команда выше напечатает HELP, потому что строка "false" — непустая, а значит, условие считается истинным.

Теперь о главном

Если хочешь использовать grep в if, не надо писать скобки!

Плохая практика:

if [ grep -q "foo" myfile ]; then
  echo "Найдено!"
fi

[... ] — ожидает условие, а не команду

grep — это команда, а не логическое выражение

Внутри [ запускать команды нельзя — это приведёт к ошибке

Хорошая практика:

if grep -q "foo" myfile; then
  echo "Найдено!"
fi

if просто запускает grep

Если grep нашёл совпадение, он вернёт 0 (успех), и выполнится then

И Всё работает как надо, без лишних скобок!

[ — это как калькулятор, а grep — это поиск. В калькуляторе искать бесполезно!

Выводы

Никогда не пиши if [ grep ... ] — это ошибка!

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

if работает с командами. [ — это тоже команда, но не синтаксис.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Позволил себе пару дней ничего не делать, кроме конечно проверки LF домашек. Лежал, исследовал дырки в axiom verge, гулял. Мне понравилось!
ㅤ
Буду почаще практиковать. Но есть и жирный минус, сегодня пришлось себя прям заставлять что-то сделать по работе. К хорошему привыкаешь быстро.

Ладно, лирика. Давай дальше бест-практики тыкать.

Команда if [ bar = "$foo" ]; проверяет, равны ли два значения.

Тут самое важно это — пробелы, про кавычки повторять не буду, ты это уже и так знаешь. Все уши тебе прожужал.

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

[bar="$foo"] 
[ bar="$foo" ]
[[bar="$foo"]]

1. Нельзя слеплять всё вместе. Это хуёва даже в плане кодстайла.
2. Нет пробела вокруг знака «=».
3. Аналогично, всё слеплено.

Правильный синтаксис:

if [ bar = "$foo" ]; then

или

if [[ bar = "$foo" ]]; then

Почему?

Потому что [, =, ] это отдельные символы, первая скобка вообще команда test. А если ты все слепляешь, Bash посчитает тебя долбаёбом и отправит в пешее эротическое.

Главное правило — всегда ставь пробелы между каждым элементом в условии.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Всё тебе, блядь, смехуюшечки да пиздахаханьки.
ㅤ
Создаём файл:

echo -e "foo\nbar\nfoo again" > bashdays.txt

Внутри получаем:

foo
bar
foo again

И применяем бэд-практику:

cat bashdays.txt | sed 's/foo/baz/g' > bashdays.txt

Эта команда читает файл bashdays.txt и одновременно пишет в него.

Что тут не так?

А всё! В лучшем случае получишь хуем по лбу и примеришь золотой пизды колпак. Эта команда испортит файл. Низя так делать! Всё проебёшь!

После этой команды файл bashdays.txt обнулится. Хотя визуально команда выглядит абсолютно безопасной.

А теперь делаем правильно!

sed 's/foo/baz/g' bashdays.txt > tmpfile && mv tmpfile bashdays.txt

Смотрим содержимое файла bashdays.txt и видим ожидаемый результат:

baz
bar
baz again

Здесь мы всё сделали через временный файл, громоздко, но по крайней мере безопасно. Веселый колпак тебе теперь точно не светит.

Можно извратиться и провернуть всё это дело на основе дескрипторов, но опять же этот способ не безопасен.

Можно правда хакнуть таким методом:

printf '%s\n' ',s/foo/baz/g' w q | ed -s bashdays.txt

Это работает без временного файла на уровне Bash, потому что ed сделаем всё сам. Но опять же конструкция нихуя непонятная.

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

🛠 #bash #badpractices #bestpractices
—
✅ @bashdays / @linuxfactory / @blog

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

Рассмотрим распространённый случай:

echo $foo

Тут всё предельно ясно и понятно. Все в ажуре!

Но это вершина айсберга. Эта команда может отрабатывать не так, как ты ожидаешь. Потому что foo это переменная. И если ты её не возьмешь в кавычки, то Bash может сделать с её содержимым всякие хитрые штуки.

Что подразумевается по «хитрыми штуками»

— Разделить содержимое на отдельные слова (если там есть пробелы).

— Подставить имена файлов с таким шаблоном, если он выглядит как *.zip (это называется глоббинг).

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

Смотри:

msg="Пожалуйста, введите имя файла в формате *.zip"
echo $msg

Выглядит опять всё красиво. А по факту получаешь:

Пожалуйста, введите имя файла в формате awscliv2.zip

Да блядь! А я просто хотел вывести строкой *.zip а не получить список файлов в текущей папке.

var="*.zip"
echo "$var"
echo $var

Первое echo напечатает *.zip, а второе выведет список всех файлов, которые заканчиваются на .zip.

Поэтому, если ты хочешь наверняка вывести переменную как есть, лучше используй `printf`

printf "%s\n" "$foo"

Для маленьких:

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

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

Хотя у каждого свой ожидаемый результат… возможно кавычки вовсе и не потребуются.

Такие дела. Изучай!

🛠 #bash #badpractices #bestpractices
—
✅ @bashdays / @linuxfactory / @blog