Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
نمایش بیشتر📈 تحلیل کانال تلگرام Bash Days | Linux | DevOps
کانال Bash Days | Linux | DevOps (@bashdays) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 23 628 مشترک است و جایگاه 5 595 را در دسته فناوری و برنامهها و رتبه 27 645 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 23 628 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 06 نوامبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -8 و در ۲۴ ساعت گذشته برابر -4 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 21.78% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 10.62% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 5 146 بازدید دریافت میکند. در اولین روز معمولاً 2 510 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 12 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند bashdays, linux, bash, docker, скрипт تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 07 نوامبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
while :
do
done
while true
do
done
Вопрос: почему в первом случае используется «:», а во втором «true»?И тут начинается… у людей включается javascript мышление и они начинают троить. Раз есть задача, значит есть и разница в поведении, значит будут какие-то разные ожидаемые результаты. Рисуют мне какие-то формулы, строят гипотезы, даже пытаются доказать свою правоту и послать меня на хуй. Ведь как происходит, пишешь ты годами bash скрипты и даже не задумываешься, а схренали я использую «:» а не «true»? Да потому что оно нахер не всралось про это думать, работает и ок. На самом деле эти циклы делаю одно и тоже. Объяснение простое: Команда «:» всегда возвращает 0. Да «:» это команда, попробуй её запустить, а следом выполнить
echo $? и получишь 0.
Эта пустая команда, которая ничего не делает и всегда завершается успехом. Ее используют, там где в синтаксисе скрипта требуется какая-либо команда.
Для while справедливо требуется продолжение, вот мы и продолжаем с помощью «:» чтобы интерпретатор не засыпал ошибками. Этакая заглушка, для синтаксической корректности.
Ну а так как true тоже команда и всегда возвращает статус 0, получается что «:» и true = идентичны. Просто написать двоеточие намного быстрее.
Хотя с другой стороны, если писать true, то код становится более читаемым.Ноги растут из древних Bourne Shell, где не было встроенных команд ни true ни false. Использовали именно «:». Получается «:» легаси? Ну можно и так сказать. Если хочешь чтобы твои скрипты работали в древних оболочках, используй «:». А если похер, то делай true. Вот что лучше читается?
if true; then
echo "hello bashdays"
fi
if :; then
echo "hello bashdays"
fi
Мне очевиднее первый вариант, если не знать за «:», то словишь ступор. Такие дела. Изучай.
tags: #linux #bash
—
@BASHDAYSРеклама. ООО «Отус онлайн-образование», ОГРН 1177746618576B105F00D = BIOS food B16B00B5 = big boobs 0B00B135 = boobies DEADBABE = dead babe E11TE = eliteДа чо далеко ходить, вон в исходных кодах полно
Про magic numbers писал тут.Кто всю эту тему раскачал хуй знает, видимо народное творчество. Смысл ты наверное понял, как все это кодируется. Но вкратце: символ «0 - ноль» может быть буквой «О», а «1» = «L» или «I» ну и т.д. Короче это гиковская культура. Теперь смотрим на картинку к посту. Если открыть JAVA файл c классом в редакторе, его первая строка будет выглядеть как «cafe babe». Первые четыре байта. Это магическое число используется для идентификации классов JAVA. А почему вообще «cаfe babe»? На самом деле предположений много разных. Но позже Джеймс Гослинг (батя JAVA) все прояснил. Они вечно тусовались в кофейне, которое прозвали «CAFE DEAD». На самом деле там длинная история, погуглите. Ну и вот, в процессе работы Джеймсу понадобилось заебенить магическое число, а «CAFE DEAD» как раз представляло шестнадцатеричное число. Ну и он его запихал для формата объектного файла. Короче ничо специально не делалось, все произошло в моменте. Про популярные комбинации хекспиков, можешь глянуть на википедии. Давай, завтра увидимся, а на выходные уж отдохнем. tags: #linux — @BASHDAYS
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576Это как если к слову «хлеб» применить XOR, то получится «пиво»Смотри:
echo -e $(printf '\\x%x' $[ 64#{L,I,N,U,X} + 29 ^ 28 ])
echo -e $(printf '\\x%x' $[ 64#{P,U,R,I,D} + 29 ^ 28 ])
Сразу пример, туда-обратно. Что тут происходит? Если кратно — происходят вычисления.
Для слова «Linux» в фигурных скобках применяется Bash Brace Expansion, который приводит слово к такому виду:
`L`,`I`,`N`,`U`,`X`
Арифметическое действие происходит в «$[». А решетка + 64 означает, что числа будут интерпретированы как шестидесятеричные (в системе счисления по основанию 64).
В итоге получаем число, которое будет вычислено как комбинация ASCII-кодов символов L, I, N, U, X (в шестидесятеричной системе) + 29, взятое по модулю 28 (используется оператор ^ как побитовое исключающее ИЛИ).
Ну и echo -e = разрешаем интерпретацию escape-последовательностей в строке.
Кринжатина? Еще какая! А сейчас давай оверхед на perl:
perl -E 'say map { chr(ord($_) ^ 28) } qw(L i n u x)'
perl -E 'say map { chr(ord($_) ^ 28) } qw(P u r i d)'
Где это можно применить, понятия не имею. Возможно это как-то натолкнет тебя на правильные мысли и ты решишь изучить методы шифрования.
Ладно, не смею больше насиловать твой чистый разум. Изучай!
tags: #bash #linux
—
@BASHDAYS/dev/full.
/dev/full — это специальный файл устройства, источник данных, который всегда возвращает ошибку «No space left on device».При попытке записи в
/dev/full, тебе выдаст — опа, а места нету! Даже если физически место есть.
Это удобно для тестирования софта и обработчиков исключений. Например, пишет твой скрипт в файл какую-нибудь суету, место закончилось. Что будет дальше делать скрипт? Как он себя поведет?
Держу пари, будет пытаться продолжать писать. А по-хорошему, он должен сообщить тебе про это, либо корректно завершиться и освободить файл. Смекаешь?
Вот пример скрипта:
#!/bin/bash
output_file="data.txt"
while true; do
# Записываем данные в файл
echo "bashdays data" >> "$output_file"
# Проверяем на "No space left on device"
if ! echo "bashdays data" >> "/dev/full"; then
echo "Disk is full!"
break
fi
done
Скрипт при каждой итерации проверяет заполнен ли диск и если заполнен то выводит сообщение «Disk is full!».
Символ «!» в этом примере = инвертирует результат выполнения команды. То есть если запись в /dev/full не вызывает ошибки, то диск еще не заполнен.
Echo можешь заменить например на триггер, который тюкнет тебе в телеграм и скажет, что твой скрипт сожрал всё место.
Как взаимодействовать с API телеграм через Bash, я писал тут.Такие дела. Изучай. tags: #bash #linux — @BASHDAYS
Перед тем как откроешь спойлера, попробуй сам решить эти задачки и закинуть свои наработки в комментарии. Чьи решения наберут больше реакций/лайков — получатЧо по плюшкам 1. Аналоговая шаурма/тортик/пиво/другое. Макс закинет тебе приятный бонус на РФ карточку. 2. Статус в чатике - воин дракона (ну или какой сам захочешь). А вот и самые короткие решения от моих студентов. Я предварительно их сломал, копипаста не сработает. Сначала подумай и пофикси, приключений на пару минут.пиздюдейприз.
В комментах закинул скриншоты с рабочих вариантов.Таблица умножения printf '%3s%3s%3s%3s%3s%3s%3s\n' $[{1..9} * {1..8}] Шахматная доска printf '%b%b%b\n' {1..4}'\b'{{1..5}'\b\e[107m \e[m ',{1..4}'\b \e[107m \e[m'} Дерзай, сегодня наверное еще увидимся. Хорошего тебе дня! А я побежал дальше graylog ковырять. tags: #bash #linux #games — @BASHDAYS
Зомби-процесс в Linux - это процесс, который завершил выполнение своей работы, но оставил запись в таблице процессов, ожидая, чтобы родительский процесс запросил информацию о его завершении. Пока родительский процесс не сделает это, запись о зомби-процессе останется в системе.Всё, с теорий хватит. Чтобы потыкать палкой какой-нибудь зомби процесс, нужно его искусственно создать. Пишем на СИ портянку (ниже будет и на Bash):
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>
int main() {
pid_t child_pid;
child_pid = fork();
if (child_pid > 0) {
sleep(7200);
} else if (child_pid == 0) {
printf("Дочерний процесс выполнен.\n");
exit(0);
} else {
perror("Ошибка при вызове fork");
exit(EXIT_FAILURE);
}
return 0;
}
Этот код создает дочерний процесс, который сразу же завершается. Родительский процесс ждет 2 часа и затем завершается без вызова wait(). Вот так мы и получим своего маленького зомби, над которым будем ставить эксперименты.
Компилируем и запускаем в фоне этого зомбаря:
gcc zombie.c -o zombie
./zombie &
Либо создаем зомби через Bash:
(sleep 1 & exec /bin/sleep 7200) &
Выполняем команды и наблюдаем zombie процесс:
ps aux | grep Z
Вывод на экран:
root 1669051 Z 14:09 0:00 [zombie] <defunct>
Ага, хорошо, зомби завели. Теперь как это дело всё закилить. Простой kill -9 PID не поможет, так как PID родительского процесса будет отличаться от дочернего.
Чтобы найти PID родителя, смотрим:
ps ax | grep zombie
Кто-то грепает по слову defunct, тут уже по потребностям выбирай.
Видим все PIDы и родителя и дочернего:
1669050 S+ 0:00 ./zombie
1669051 Z+ 0:00 [zombie] <defunct>
В моем случае PID родительского = 1669050, а дочернего 1669051, который собственно и есть зомбик.
Теперь накидываем однострочник:
kill -9 $(ps -A -ostat, ppid | grep -e '[zZ]'| awk '{ print $2 }')
Эта штука найдет все зомби процессы и уничтожит их. Даже не нужно никакие циклы на Bash колхозить.
А если требуется регулярно зачищать зомборей, вешаем однострочник на cron и радуемся.
Вообще это самый простой способ закилить эту каку. Как это сделать через gdb напишу на следующей неделе. Но сразу предупреждают, там оверхед решение и скорее всего оно тебе не понравится. Хотя через gdb можно оставить в живых родительский процесс и убить только дочерних зомбаков.
В большинстве случаев не стоит обращать внимание на этих зомбаков, эти процессы не жрут ресурсы, а являются лишь косяками программного обеспечения.У меня зомбаки порой случались с nginx на древней CentOS, но после апгрейда на убунту, все прошло. Если сможешь что-то еще добавить, пиши в комменты, будет всем полезно. Давай, хороших выходных, не болей! tags: #bash #linux — @BASHDAYS
Более подробно про сигналы я писал в этом постеДавай к примерам:
sleep 120 &
pid=$!
kill -0 $pid && kill $pid
fg
1. Запускаем в фоне задачу sleep
2. Присваиваем переменной PID процесса
3. Проверяем, если процесс с $pid запущен, то убиваем его
4. Проверяем что процесс убит
Здесь мы с помощью нуля проверили наличие запущенного процесса и на возможность отправлять ему сигналы. Если всё ок, то отрабатывает команда kill $pid.
А если запустить так:
kill -0 $pid; echo "Exit status: $?"
Получим статус выхода. То есть процесс не запущен и можно смело выходить со статусом 1.
Про статусы и коды возврата можешь почитать в этом посте.Ну и напоследок проверим, может ли пользователь отправлять сигналы процессы. Запускаем под обычным пользователем:
sudo sleep 120 &
kill -0 $!; echo "Exit status: $?"
В итоге получим:
bash: kill: (1644755) - Operation not permitted
Exit status: 1
То есть запускаем фоновый процесс от рута, а затем с помощью нуля проверяем, сможет ли обычный пользователь убить этот процесс. Как видим - хуй, не сможет.
В нормальной жизни я редко встречал скрипты с такими конструкциями и проверками, но тот кто профессионально пишет для opensource это прям мастхев, суют везде, мама не горюй.
Хорошего дня, а я пошел дальше диван давить, да лечиться. Увидимся!
tags: #bash
—
@BASHDAYS1. help printf
2. printf --help
3. env printf --help
НО. Каждая команда выведет свою версию справки (почти). То есть результат вывода будет отличаться в разных случаях. Не веришь? Попробуй сам.
В первом пункте с help printf всё понятно. Получишь некий огрызок, который трудно назвать страницей помощи. Да и во втором тоже самое.
В 1-2 вызывается именно встроенная утилита printf в оболочку Bash. А вот в третьем пункте, выведется достаточно внушительный хелп.
И этот внушительный хелп будет от схожей, внешней утилиты printf, которая располагается тут: /usr/bin/printf.
Посмотреть все варианты printf можно так:
type -a printf
На экран выведется список:
printf is a shell builtin
printf is /usr/bin/printf
printf is /bin/printf
Ну и везде советуют пользоваться встроенной в Bash командой help, она нативнее и поддерживает почти весь синтаксис оболочки. Тут уже решать тебе.
Я очень редко читаю документацию таким способом, предпочитаю сразу загуглить. Ладно. Изучай.
tags: #bash
—
@BASHDAYSТакое происходит только в фильмах, но увы, порой я думаю, что живу в каком-то сценарии Тарантино.Проанализировав произошедшее, в очередной раз убедился, что от apple и кубернейтсов одно зло. Linux / Windows / Android / Bash / Ctypes наше всё. Таску в джире пометил как кот - Blocked, а ноут выставил на авито. Так что будь аккуратнее если решишь купить б/у железяку, возможно ранее в её красиво
git clone https://github.com/taviso/ctypes.sh.git
cd ctypes.sh
./autogen.sh
./configure
make
sudo make install
По умолчанию вся эта байда ставится в папку /usr/local/bin и /usr/local/lib. Но при сборке путь можно изменить через параметр PREFIX=$HOME make install.
Так собрали, установили. Чо дальше? А дальше пишем самую простую so библиотеку:
#include <stdio.h>
void hello_bashdays() {
printf("Hello, Bashdays!\n");
}
Компилируем:
gcc -shared -o /tmp/bashdays.so bashdays.c
На выходе получаем готовый файл bashdays.so с функцией hello_bashdays. Проверяем какие символы доступны в скомпилированной библиотеке:
nm -g /tmp/bashdays.so
Команда nm покажет, все глобальные функции и переменные, которые доступны в библиотеке bashdays.so. Мне выдало такое:
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w __cxa_finalize@GLIBC_2.2.5
w __gmon_start__
0000000000001119 T hello_bashdays
U puts@GLIBC_2.2.5
Ок. Всё верно! Символ T перед названием функции, означает, что функция глобальная. А символ U (puts) = что эту функцию можно вызвать из вне.
Ну и теперь с помощью ctypes мы можем вызвать эту функцию из Bash скрипта.
#!/bin/bash
source /usr/local/bin/ctypes.sh
dlopen "/tmp/bashdays.so"
dlcall "hello_bashdays"
Опа нихуя! На экран получаем результат выполнения СИ функции hello_bashdays. Собственно Hello, Bashdays!
И это всего лишь верхушка айсберга, если копнуть глубже…
Вот несколько отзывов на ctypes:
- Это отвратительно
- Это должно прекратиться
- Вы зашли слишком далеко
- Это шутка?
Вот такие интересные штуки существуют. Надеюсь тебе понравилось. Теперь ты знаешь как собирать shared so файлы и легко вызывать от туда функции.
Аа забыл, как заансетить переменную:
readonly VAR=123
source /usr/local/bin/ctypes.sh
dlcall unbind_variable string:VAR
Вот и все. И никаких тебе танцев с gdb. Переменная VAR обнулена.
Примени это с умом, ведь на тёмную сторону перейти очень легко. Увы, но я уже там!
🌐 Страница проекта на github
tags: #bash #linux
—
@BASHDAYS