Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
Показати більше📈 Аналітичний огляд Telegram-каналу Bash Days | Linux | DevOps
Канал Bash Days | Linux | DevOps (@bashdays) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 23 735 підписників, посідаючи 5 559 місце в категорії Технології та додатки та 27 925 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 23 735 підписників.
За останніми даними від 01 серпня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 2, а за останні 24 години на -5, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 21.76%. Протягом перших 24 годин після публікації контент зазвичай збирає 12.80% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 5 165 переглядів. Протягом першої доби публікація в середньому набирає 3 037 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 23.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як bashdays, linux, bash, docker, скрипт.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
Завдяки високій частоті оновлень (останні дані отримано 02 серпня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
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
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576Нет, не от злых черно-шляпных, смысла в этом мало, блокировка тут не решает. Собаку съели.Дело было так. Лет 10 назад я открыл
putty, подключился к проду и пошел навалить себе кофеёв с печенькой. Навалил. Вернулся. На клавиатуре мило устроился кот.
Кота тревожить не стал, уважительная причина не ходить на работу. Взял ноут и получил в аську 100500 алертов в nagios.
Да, в те времена в тренде были nagios и заббиск. Но заббикс всем казался пиздец сложным, поэтому халявили и втыкали нагиос.
Ну дак вот. Суть.
Когда кот устраивался, он первой лапой нажал на стрелочку вверх, потом еще раз нажал пузаном и на фаталити ёбнул яйцами по Enter.
Ему то чё, он хуй за мясо не считает.А в хистори с профилактических выходных оставалась команда
shutdown -h now, до которой добрался кот и успешно её исполнил.
В те времена мелкий бизнес особо за аптайм не переживал и ретроспективы только зарождались, в жопы не ебали.Но опыт был получен.
Звучит как сказка, но такие сказки со мной постоянно приключаются, коллеги соврать не дадут.Вот после этого, я всегда жму
WIN + L или CMD + Q.
Даже если кот и сын спят, все равно прожимаю эту комбинацию.
Но опять же если открыта консолька с продом, то заранее её еще и сворачиваю, впизду.
Видимо детская травма.
А ты прожимаешь WIN + L / CMD + Q если отходишь от своей рабочей лошадки?
Камон в комменты делиться своими факапами.
tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgateif [ 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Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576grep 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[[ $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[ "хуи" = "коробка1" -a "пики" = "коробка2" ]
Тут -a (И) считается устаревшим и в некоторых случаях это работать не будет. Так что если такое видишь или пишешь, сразу сноси, это хуйня!
Одна из проблем с [ A = B -a C = D ] (или -o) в том, что POSIX не определяет, как должна работать команда [ ... ], если у неё больше 4 аргументов.Бест-практика: Разделяем на две проверки:
[ "коробка1" = "хуи" ] && [ "коробка2" = "пики" ]
Сначала проверяется первое условие, затем второе.
Если оба верны — команда выполнится.
Либо делаем конкретно под Bash:
[[ "коробка1" = "хуи" && "коробка2" = "пики" ]]
Здесь можно использовать &&, всё будет работать правильно.
Выводы:
Если используешь [ ... ], то делай две отдельные проверки.
Если [[ ... ]], то можно писать всё внутри.
tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgatef="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[ $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Алёша, ты чё блядь Супер Марио? Об грибок уебался?Что делать с упавшим продом? Естественно чинить самому! В этой ситуации ты можешь положиться только на себя. Ты тот самый Брюс Уиллис, который полетел в космос и выебал астероид. Тут уже никто не спрашивает — можешь ты это починить или нет. Ты обязан с этим разобраться и починить. А как? Вообще никого не ебет — предоставьте результат. Из помощников только гугол, твоя насмотренность и опыт. Больше положиться не на кого, ты гуглиш, экспериментируешь, по итогу чинишь всё это дерьмище и чилиш. Ну и надеешься чтобы на ретро тебя в жопу не выебали. Ситуация вторая Ты не единственный специалист в своей роле. Аналогично, ты что-то запушил в мастер и все уебалось. Что ты делаешь? Пытаешься починить, не выходит, еще раз пытаешься, гуглишь, используешь нейросети, становится только хуже… Следующий твой шаг — делегируешь свой факап своему коллеге (коллегам, тегаешь всех
@channel), у них опыта больше, наверное посоветуют, разберутся.
Это сразу провальный вариант!
➡️ Если что-то сломал — чини сам! Это аксиома!
Но опять же если это прод, не грех посоветоваться с коллегами, если такие есть. Всеобщими усилиями это поднять, а потом уже жопу свою на ретро отдать на экзекюцию, но не забыть заранее выписать бочку вазелина с Озона.
Короче вывод такой — никогда ни на кого не надейся!
Сразу в башке носи мысль — ты один и разбираться с этим тебе одному.
Такой подход неистово качает твой скиллз и ты никогда не будешь зависеть ни от кого. И это очень ценный навык в айти, кем бы ты ни был.
Как только ты станешь самостоятельным, тебе будет похер вообще на всё и на всех, ты будешь Альфа-Ктулху, который решит любую проблему!
Такие дела, нового ничего не сказал, рабочие будни.
tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate