И на старуху бывает проруха...
ㅤ
🔤🔤🔥🔤🔤🔤🔤

Сегодня решил поделиться отрицательным опытом. Код, приведенный в статье лучше не использовать.

У меня возникла необходимость распарсить файл типа:

xxx yy "zz zz zz zz"

Видно, что однословные поля разделены пробелом, а многословные заключены в кавычки. Распарсить такой файл на awk можно, но не быстро. Нужно писать код.

А на bash - вроде просто:

set -- xxx yy "zz zz zz zz"
echo $# $1 $2 $3

# 3 xxx yy zz zz zz zz

Проверил — вроде работает. Классно, пишу цикл, проверяю на файле — не работает. Упрощаю код до минимума.

REC='xxx yy "zz zz zz zz"'
set -- $REC
echo $# $1 $2 $3

# 6 xxx yy "zz

Очевидно, разбились по пробелам. Перепробовал кавычки — не выходит. Не придумал ничего лучшего, как использовать конструкцию:

REC='xxx yy "zz zz zz zz"'
eval "set -- $REC"
echo $# $1 $2 $3

# 3 xxx yy zz zz zz zz

Все работает как надо.

После этого я решил распарсить реальный лог apache.

Все работало прекрасно, но на определенной строчке все зависало на несколько секунд, а потом продолжалось. Начал разбираться, и когда понял, что происходит — чуть не поседел.

Там была инъекция:

$(ping${IFS}-c${IFS}6${IFS}aa.bb.cc.dd)

Переменная IFS использовалась вместо пробела. Короче, команда выглядела так:

ping -c 6 aa.bb.cc.dd

Ничего страшного. Просто пинг 6 раз на адрес. И этот пинг ИСПОЛНЯЕТСЯ, вызывая задержку. Но команда могла быть и другой. Спасибо дядям за доброту.

Проблема возникла из-за того, что оператор eval разворачивал не только мою переменную, а все переменные, в том числе и из лога, попутно выполняя команды.

В общем, если я раньше считал оператор eval — бесполезным, то теперь я считаю его вредным.

Вот такой опыт.

tags: #bash #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

Вот всё трём мы с тобой за бест-практики, но практически ничего не разбираем по бэд-практикам.
ㅤ
Давай это исправлять в контексте Bash скриптов.

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

Естественно будет серебряная пуля — как сделать правильно.

Ну чё, готов? Тогда поехали!

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

Допустим, у тебя есть переменная $file, в которой как ни странно хранится имя файла. И есть $target, в ней мы указываем путь куда скопировать файл.

Если мы пишем:

cp $file $target

То возникает проблема, Если имя файла содержит пробелы, то Bash ясен хуй разобьет эту строку на пробелы:

file="You can suck my dick.avi"

Команда превращается в такое:

cp You can suck my dick.avi /tmp

И это воспримется интерпретатором как копирование нескольких файлов:

You
can
suck
my
dick.avi

Дальше. Если в имени файла ($file) будут символы *, ?, [ ], то это интерпретируется как шаблон для поиска файла.

Так называемое — Pathname Expansion.

Ага. Теперь если в имени файла содержится символ -, к примеру твой файл называется: -bashdays.txt, то команда cp расценит, что ты указал флаг и выебет тебя в глаз.

cp -bashdays.txt /tmp

cp: ну ты ебать инвалид -- 'h'
Try 'cp --help' for more information.

Как правильно?

Вот так:

cp -- "$file" "$target"

Кавычки в данном контексте предотвратят разделение на пробелы и ошибочное расширение подстановок.

Но если сделать так:

cp "-bashdays.txt" "/tmp"

cp: еще и баран -- 'h'
Try 'cp --help' for more information.

Чтобы не быть «инвалидом и бараном» нужно после cp вхерачить --.

Эти два тире напомнят cp что дальше идут только файлы, а никакие-то флаги.

Каков итог?

Думаю ты и сам выводы сделал. Всегда пиздярь кавычки вокруг переменных в Bash.

Даже если работает без кавычек это ничего не значит, не ровен час получишь по ебалу.

Например твой скрипт будет выполняться в другом окружении, где $IFS (разделитель слов) изменён или файлы содержат пробелы и спецсимволы.

В общем сразу мотай на ус эту тему, подстели соломку и пиши скрипты как профи.

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

Продолжаем погружаться в Бэд-Практики!
ㅤ

предыдущие посты о том, что это такое ищи по тегу #badpractices

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

Как это победить мы с тобой уже знаем, завернуть в кавычки и кинуть два дефиса:

cp -- "$file" "$target"

Что означают 2 дефиса опять же смотри предыдущие посты по тэгу #badpractices

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

Второй способ разруливания этой ситуации — указать путь к файлу.

Смотри. Если перед именем файла добавить ./ (означает текущую папку), то даже если файл называется -bashdays.txt он будет передан в команду правильно.

for i in ./*.txt; do
    cp "$i" /tmp
done

В этом случае cp не затроит и выполнит задуманное.

Ну и еще вариант на закуску.

Можно просто ебануть ./ перед именем файла при передачах в команду:

for i in *.txt; do
    cp "./$i" /tmp
done

Этот варик немного сэкономит ресурсы, тут не требуется дополнительных вычислений для обработки имен файлов. Но при условии, что у тебя немного файлов. Если их будет дохуя, то увы, будет тормозить.

Выводы

Лучший вариант — всегда указывать путь к файлу (относительный ./ или полный /home/user/...). Это избавит тебя от большинства проблем с файлами которые начинаются с дефиса.

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

Привет друзья, наш товарищ Sf1nk5 подготовил внушительную статью про CrowdSec. За что ему объявлена благодарность.

CrowdSec — это система защиты от кибератак, которая использует анализ поведения и коллективную защиту. Она похожа на Fail2Ban, но более мощная и современная.

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

Так что запасаемся кофеём/пивком и камон 👇

➡️ Всё что нужно знать про CrowdSec

tags: #security
—
🔔 @bashdays➡️ @gitgate

Вчера после статьи про CrowdSec много ребят обратились с вопросом — мужик, а чё за движок такой у твоего блога?

Отвечу сразу всем. Это не движок, это статика. И сделана она при помощи фреймворка MKDocs + Material.
ㅤ
Суть там простая, верстаешь статейки в markdown, пушишь в гит репу, оно собирается в статику и автоматом выкатывается в прод.

Скорость работы по сравнению с wordpress просто ебейшая (статика хули). Сейчас занимаюсь SEO оптимизацией, роботсы, сайтмепы и т.п.

Порог вхождения прям минимальный.

А самое главное — отлично написанная документация. Можно чёрта закостомить, реврайтить базовые вещи, js писать, полностью менять верстку. Но обычно коробочных приколюх уже достаточно.

Плюс к этому полно роликов на ютубе, как эту чачу заводить и размещать на серверах.

Базовый файл requirements.txt выглядит так:

mkdocs
mkdocs-material
mkdocs-material-extensions

В моём случае я просто подключил нативный плагин блога в mkdocs.yml и немного его сконфигурял.

plugins:
  - search
  - tags
  - blog:
      blog_dir: .
      blog_toc: false
      archive_name: Архив
      archive_toc: false
      archive_date_format: yyyy
      archive_url_date_format: yyyy
      authors_file: "{blog}/.authors.yml"
      post_url_format: "{slug}"
      post_date_format: short
      pagination: true
      pagination_per_page: 5
      draft: true
      draft_on_serve: true
      post_readtime_words_per_minute: 300

Больше боли мне доставило написать пайплайн для gitea, но я поборол этого босса и вечерком скину наработки. Глядишь под гитхаб адаптируешь, там синтаксис почти один в один.

Gitea использую для личных проектов, без всяких наворотов, встроенного CI/CD и раннера вполне хватает.

Настоятельно рекомендую потыкать этот Mkdocs с полезной нагрузкой Material, я прям в восторге прибываю.

И да, это отличный способ развернуть свою личную wiki и не ебстись со всякими конфлюенсами и т.п. Ну либо документацию к проектам к своим описывать тоже маст-хевная штукенция.

Кстати в GitGate оно как-то от Димы уже прилетало, но там про material не упоминалось.

Ладно, не смею тебя больше отвлекать, вечерком еще увидимся.

tags: #рабочиебудни #frameworks
—
🔔 @bashdays➡️ @gitgate

Такс, как и обещал притаранил тебе рабочий пайплайн для авто деплоя mkdocs через gitea.
ㅤ
Чтобы всё это заработало, в проекте тебе нужно создать структуру:

.gitea/workflows/deploy.yml

Файл можешь обозвать как угодно.

name: Build and Deploy Bashdays Blog

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: super-runner
    container:
        image: catthehacker/ubuntu:act-22.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies and build
        run: |
          pip install -r requirements.txt
          mkdocs build

      - name: Deploy to Server
        uses: https://gitea.com/aquelle1/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc -i --delete" 
          SOURCE: "site/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Давай пробежимся:

Триггер on: push: запускается если что-то запушено в ветку main.

Почему в main а не в master? Читай тут.

Следом запускается джоба build на раннере super-runner, не забываем зарегать себе раннер, без него нихуя не получится.

Что такое раннеры и как с ними работать, можешь загуглить, там по сути ничего сложного. Поэтому этот этап пропущу. Чуть позже отдельным постом запилю про это.

Дальше используем адаптированный контейнер с убунтой 22.04 специально адаптированный под тестирование GitHub Actions через act.

Почему GitHub Actions? Потому что gitea унаследовало синтаксис и пайплайны в теории могут переносится между системами.

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

Потом идут шаги speps, клонируется репозиторий с проектом в контейнер, устанавливаются необходимые зависимости через «пипку», ну и билдится финальная статика.

После сборки идет секция с деплоем, я использую этот экшен. Основан он на rsync поверх ssh.

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

SSH_PRIVATE_KEY = Приватный ssh ключ с которым раннер пойдет на твой сервер и подключиться по ssh к нему. Соответственно публичная часть ключа должна быть прописана у пользователя на сервере в файле ~/.ssh/authorized_keys.

Как работать с ssh ключами, читай по тегу #linuxfactory

ARGS = Аргументы для rsync, рекурсивное копирование, сохранение прав доступа, удаление файлов которые не в локальной версии.

SOURCE = Какой каталог со статикой отправляем. В Mkdocs статика генерится по умолчанию в папку site.

REMOTE_HOST & REMOTE_USER = Айпишник или домен продакшена на который деплоим + имя пользователя под которым подключаемся к серверу.

TARGET = В какую папку на проде скинуть содержимое папки site.

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

Вот и всё. Теперь при пуше в main ветку, автоматически запустится пайплайн и на прод выкатятся изменения.

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

Короче хорошего тебе вечера, теперь уже до завтра!

tags: #devops #cicd
—
🔔 @bashdays➡️ @gitgate

Представь, ты работаешь в компании единственным специалистом в своей роле.

Ну, то есть ты ОДИН фронт/бекендер/девопс/qa и т.п. Тимлида в такой ситуации обычно не бывает, максимум есть СТО (техдир) и то он родственник CEO.
ㅤ
Возникает ситуация — ты что-то закомитил, прод уебался. С кого спрос?

Само собой с техдира, а дальше клубочек ведет уже к тебе. И хуй ты там стрелочку переведешь, банально некуда.

А техдир давно не советчик (не помощник), по причине — максимальная деградация и просиживание штанов на созвонах.

Всё что ты получишь:

Алёша, ты чё блядь Супер Марио? Об грибок уебался?

Что делать с упавшим продом? Естественно чинить самому!

В этой ситуации ты можешь положиться только на себя. Ты тот самый Брюс Уиллис, который полетел в космос и выебал астероид.

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

Из помощников только гугол, твоя насмотренность и опыт. Больше положиться не на кого, ты гуглиш, экспериментируешь, по итогу чинишь всё это дерьмище и чилиш.

Ну и надеешься чтобы на ретро тебя в жопу не выебали.

Ситуация вторая

Ты не единственный специалист в своей роле. Аналогично, ты что-то запушил в мастер и все уебалось.

Что ты делаешь? Пытаешься починить, не выходит, еще раз пытаешься, гуглишь, используешь нейросети, становится только хуже…

Следующий твой шаг — делегируешь свой факап своему коллеге (коллегам, тегаешь всех @channel), у них опыта больше, наверное посоветуют, разберутся.

Это сразу провальный вариант!

➡️ Если что-то сломал — чини сам! Это аксиома!

Но опять же если это прод, не грех посоветоваться с коллегами, если такие есть. Всеобщими усилиями это поднять, а потом уже жопу свою на ретро отдать на экзекюцию, но не забыть заранее выписать бочку вазелина с Озона.

Короче вывод такой — никогда ни на кого не надейся!

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

Такой подход неистово качает твой скиллз и ты никогда не будешь зависеть ни от кого. И это очень ценный навык в айти, кем бы ты ни был.

Как только ты станешь самостоятельным, тебе будет похер вообще на всё и на всех, ты будешь Альфа-Ктулху, который решит любую проблему!

Такие дела, нового ничего не сказал, рабочие будни.

tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

Когда в Bash ты сравниваешь две переменные, важно не проебаться с кавычками.

[ $foo = "bar" ]

В этом примере если переменная $foo будет пустой, то по итогу ты попадешь в просак:

[ = "bar" ]

bash: [: =: unary operator expected

Логично вылезет ошибка, потому что «=» ожидает два значения. Чтобы избежать этой ситуации, на помощь приходят — кавычки.

[ "$foo" = "bar" ]

Теперь всё в поряде. Ошибки никакой нет.

Но Bash не пальцем деланный, поэтом сравнить две переменные можно иначе.

[[ $foo == bar ]]

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

Есть еще легаси способ:

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

В современном мире ты вряд ли с ним столкнешься, но в каких-то допотопных скриптах вполне можешь найти.

Если $foo пустая, то без x получится:

[ = bar ]

А с x будет:

[ x = xbar ]

В [[ ... ]] переменные не разделяются на слова, даже если содержат пробелы.

foo="hello bashdays"
[[ $foo = "hello bashdays" ]]

А если сделать так:

foo="hello bashdays"
[ $foo = "hello bashdays" ]

Получишь ошибку: bash: [: too many arguments

Все это справедливо для Bash. Если пишешь под sh, то твой путь это одинарные скобки [...].
ㅤ
А еще в двойных скобках можно использовать шаблоны:

foo="hello bashdays"
[[ $foo == h* ]]

Вернёт true, потому что foo начинается с «h».

Либо написать сложное условие:

[[ $foo = "bar" || $bar = "baz" ]]

В одинарных кавычках это выглядело бы так:

[ "$foo" = "bar" -o "$bar" = "baz" ]

Выводы:

Всё что тебе нужно знать это первые два способа:

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

Это трувей, бестпрактика и мастхев.

Изучай.

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

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

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

Представь, что у тебя есть две коробки. На одной написано «хуи дрочёны», а на другой «пики точены».

Ты хочешь проверить:
ㅤ
— В первой коробке хуи?
— Во второй коробке пики?

Если оба условия верны, ты говоришь — заебись!.

Бэд практика:

[ "хуи" = "коробка1" -a "пики" = "коробка2" ]

Тут -a (И) считается устаревшим и в некоторых случаях это работать не будет. Так что если такое видишь или пишешь, сразу сноси, это хуйня!

Одна из проблем с [ A = B -a C = D ] (или -o) в том, что POSIX не определяет, как должна работать команда [ ... ], если у неё больше 4 аргументов.

Бест-практика:

Разделяем на две проверки:

[ "коробка1" = "хуи" ] && [ "коробка2" = "пики" ]

Сначала проверяется первое условие, затем второе.

Если оба верны — команда выполнится.

Либо делаем конкретно под Bash:

[[ "коробка1" = "хуи" && "коробка2" = "пики" ]]

Здесь можно использовать &&, всё будет работать правильно.

Выводы:

Если используешь [ ... ], то делай две отдельные проверки.

Если [[ ... ]], то можно писать всё внутри.

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

Если написать так [[ $foo > 7 ]], то далеко не факт что это правильно отработает.
ㅤ
Двойные скобки [[ ... ]] в Bash предназначен для проверки условий, но не для работы с числами. Для чисел лучше хуячить (( ... )).

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

(( foo > 7 ))

А если хочется прям строго соответствовать POSIX, делай так:

[ "$foo" -gt 7 ]

Теперь давай разберемся почему с [[ $foo > 7 ]] словишь ошибку.

Символ > в [[ ... ]] сравнивает строки, а не числа. Например, "10" < "7", потому что 1 идёт раньше 7 в алфавите.

В [...] символ > вообще означает «перенаправление вывода», и создаст файл с именем 7 в текущей папке.

Еще пример:

case $foo in
    ("" | *[!0123456789]*) echo "Ошибка: foo не число!" && exit 1 ;;
    *) [ "$foo" -gt 7 ] ;;
esac

Если $foo содержит что-то вроде $(rm -rf /), то при определённых условиях это может привести к пиздецу. Поэтому перед проверкой лучше убедиться, что $foo — это число.

Код выше проверяет, является ли переменная $foo числом, и если да, сравнивает её с 7.

case $foo in — конструкция для проверки значений переменной $foo по шаблонам.

"" — пустая строка (если $foo пустое).

("" | *[!0123456789]*) — строка, содержащая хотя бы один символ, который не цифра (например, abc, 12a3).

Если условие выполняется, выводится сообщение "Ошибка: foo не число!", и скрипт завершает работу с кодом 1 (exit 1).

* — означает «всё остальное» (то есть, если $foo не попал под первый шаблон).

[ "$foo" -gt 7 ] — проверяет, больше ли $foo чем 7.

Выводы: для работы с числами используем (( ... )) или [ "$foo" -gt 7 ], а переменные перед проверкой лучше очищать от лишних символов.

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

Продолжаем делать правильно.
ㅤ
Этот код выглядит вполне нормально:

grep foo bar.txt | while read -r; do ((count++)); done

Он считает, сколько строк в файле bar.txt содержат слово foo.

Здесь главная проблема — переменная count не изменится вне цикла while, потому что в Bash каждая команда в пайплайне (|) запускается в отдельной оболочке (subshell). То есть count++ происходит «внутри», и снаружи этого не видно.

Если простым языком: Каждая часть, разделённая |, запускается в отдельной «коробке» (subshell). То есть while работает внутри своей коробки. B всё что там происходит, не видно снаружи.

Некоторые оболочки ksh93 или Bash с включённой настройкой shopt -s lastpipe работают по-другому — цикл выполняется в той же оболочке, и тогда count изменится.

count=0
echo -e "one\ntwo\nthree" | while read line; do ((count++)); done
echo $count

Этот код вернет 0, несмотря на count++, а вот например в zsh вернется 3.

Как быть?

Первый вариант:

shopt -s lastpipe

Эта штука говорит интерпретатору — что последний элемент конвейера будет выполнен в окружении текущей оболочки.

Второй вариант:

Вообще избавиться от while и всё сделать через grep:

count=$(grep -c foo bar)
echo $count

Можно еще наколхозить и передавать значения через временный файл, но это прям пиздец шляпа и костыль.

Выводы

Нужно просто посчитать строки:

count=$(grep -c foo bar)

Нужно обрабатывать строки:

while read line; do ...; done < bar

Хочешь использовать pipe:

shopt -s lastpipe

Вот и вся наука.

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

С пятницей ребят. Бест-практики по башу уже знатно подзаебали, держись осталось немного, там за дебаг затрем, подкопилось у меня знатной дичи.
ㅤ
Сегодня поделюсь с тобой почему я стал использовать блокировку экрана перед тем как отойти от экрана.

Нет, не от злых черно-шляпных, смысла в этом мало, блокировка тут не решает. Собаку съели.

Дело было так. Лет 10 назад я открыл putty, подключился к проду и пошел навалить себе кофеёв с печенькой. Навалил. Вернулся. На клавиатуре мило устроился кот.

Кота тревожить не стал, уважительная причина не ходить на работу. Взял ноут и получил в аську 100500 алертов в nagios.

Да, в те времена в тренде были nagios и заббиск. Но заббикс всем казался пиздец сложным, поэтому халявили и втыкали нагиос.

Ну дак вот. Суть.

Когда кот устраивался, он первой лапой нажал на стрелочку вверх, потом еще раз нажал пузаном и на фаталити ёбнул яйцами по Enter.

Ему то чё, он хуй за мясо не считает.

А в хистори с профилактических выходных оставалась команда shutdown -h now, до которой добрался кот и успешно её исполнил.

В те времена мелкий бизнес особо за аптайм не переживал и ретроспективы только зарождались, в жопы не ебали.

Но опыт был получен.

Звучит как сказка, но такие сказки со мной постоянно приключаются, коллеги соврать не дадут.

Вот после этого, я всегда жму WIN + L или CMD + Q.

Даже если кот и сын спят, все равно прожимаю эту комбинацию.

Но опять же если открыта консолька с продом, то заранее её еще и сворачиваю, впизду.

Видимо детская травма.

А ты прожимаешь WIN + L / CMD + Q если отходишь от своей рабочей лошадки?

Камон в комменты делиться своими факапами.

tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

Привет, один из наших подписчиков попросил анонсировать его пепяку. Она уже пролетала в gitgate, но ничего страшного, пусть и тут полежит. Тем более штука маст-хэвная.

TENV Ёпта!

Если кратко, TENV это консольный менеджер для управления версиями Terraform, Terragrunt, OpenTofu, Atmos.
ㅤ
TENV написан на гошке, не требует дополнительных зависимостей и может быть запущен под любой операционкой. Удобно чё.

Ты скажешь — блядь, да есть же например tfenv и asdf, зачем очередной велосипед?

Во-первых, автора TENV зовут Александр, а не «Аннадурай Сатьямурти Чидамбарампиллаи». А это уже о чем-то говорит!

Ну и, во-вторых, все эти утилиты не поддерживают OpenTofu, Terragrunt и т.п. К тому же, требуют много консольных костылей/зависимостей и хуёва работают НЕ на Linux.

asdf не поддерживает автоматическое переключение версий на базе спецификации версии Terraform / OpenTofu внутри проекта с помощью HCL файлов. В целом, asdf скорее переключалка по запросу, а tenv более заточен под OpenTofu/Terraform проекты.

Установка:

LATEST_VERSION=$(curl --silent https://api.github.com/repos/tofuutils/tenv/releases/latest | jq -r .tag_name)
curl -O -L "https://github.com/tofuutils/tenv/releases/latest/download/tenv_${LATEST_VERSION}_amd64.deb"
sudo dpkg -i "tenv_${LATEST_VERSION}_amd64.deb"

Сейчас лично потыкал, всё работает как часики. После установки запускаем tenv, выбираем из списка (стрелочками и на пробел) что установить и жмем ENTER.

НО, так как хашикорпы — письки (This content is not currently available in your region), в РФ надо трафик прогнать через одно место, чтобы вытащить бинари терраформа.

Вот тут я бы пожелал автору добавить киллер-фичу, сделать чтобы tenv обращался к таким заблокированным серверам не самостоятельно, а например через какую-то прокладку. Тогда сука цены бы не было!

Александр, добавь для нас такую возможность, буду прям лично твоей штукой пользоваться, достаточно удобно!

В общем рекомендую потыкать и поддержать проект звездами. Годнота!

➡️ Страница проекта и документация

tags: #utilites #devops
—
🔔 @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