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 794 مشتركاً، محتلاً المرتبة 5 701 في فئة التكنولوجيات والتطبيقات والمرتبة 28 128 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 23 794 مشتركاً.
بحسب آخر البيانات بتاريخ 17 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -202، وفي آخر 24 ساعة بمقدار -5، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 21.91%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 12.48% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 5 213 مشاهدة. وخلال اليوم الأول يجمع عادةً 2 971 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 21.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل bashdays, linux, bash, docker, скрипт.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 18 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
direnv.
Эт полезная хуёвина для расширения оболочки. И она достаточно известна среди населения в загнивающем западе.
ㅤ
Позволяет загружать и выгружать переменные среды в зависимости от каталога.
Грубо говоря — позволяет не засирать .profile всяким дерьмом.
Работает так: перед каждым запуском оно проверяет наличие файла (.envrc или .env) в текущем или родительском каталоге.
Если такой файл существует, то он загружается в подоболочку bash. И все экспортируемые переменные становятся доступны для текущей оболочки.
Работает с большой четверкой: bash, zsh, fish, tcsh
Суть — используем переменные среды для конкретного проекта, не трогая при этом ~/.profile.Что интересно,
direnv это бинарник на golang, что уже подразумевает скорость и все плюхи связанные с этим.
Для убунты ставится так: apt install direnv
Как воткнуть это в другое место, подробно написано тут ну или спроси у медведя.Подключаем так, добавляем в
~/.bashrc:
eval "$(direnv hook bash)"
Для других шелов смотрим тут.Не забываем перечитать файл
~/.bashrc чтобы изменения вступили в силу.
Так, поставили, молодцы! Проверяем чо получилось:
cd /tmp
mkdir my-project
echo ${FOO-bashdays}
На экран выдалось: bashdays
Переменная среды FOO не вывелась, логично, дальше:
echo export FOO=foo > .envrc
Ёпта, ошибка — direnv: error /tmp/my-project/.envrc is blocked. Run `direnv allow` to approve its content.
Сработала защита от дурака, которая запретила нам использовать .envrc. Хе, ща пофиксим!
direnv allow .
Во! Лепота!
direnv: loading /tmp/my-project/.envrc
direnv: export +FOO
Повторяем первую команду:
echo ${FOO-bashdays}
Хуяк и получаем: foo
Что и требовалось доказать, direnv отлично справилась с поставленной задачей.
Теперь выходим из проекта и смотрим:
cd ..
direnv: unloading
echo ${FOO-bashdays}
Ииии барабанная дробь, у нас вывелось — bashdays!
Какая же красота и любовь с первого взгляда!
Рекомендую! Однозначно забираем себе в копилку и внедряем в свой воркфлоу, по крайней мере для всяких лабораторных испытаний эта штука подходит идеально.
➡️ Проект на гитхабе: https://github.com/direnv/direnv
⭐️ Star 12.6k
tags: #bash #linux
—
🔔 @bashdays➡️ @gitgatecat, но с потоками.
ㅤ
Конечно можно воспользоваться дополнительной утилитой parallel, но мы лёгких путей не ищем. Глаза боятся, да руки веселятся.
Вот что у меня получилось:
#!/bin/bash
file=$1
threads=4
process_line() {
line="$1"
echo $line
}
export -f process_line
fifo="/tmp/fifo"
mkfifo "$fifo"
exec 3<>"$fifo"
rm "$fifo"
for ((i = 0; i < threads; i++)); do
echo >&3
done
while IFS= read -r line; do
read -u 3
{
process_line "$line"
echo >&3
} &
done < "$file"
wait
exec 3>&-
Не забываем chmod +x pcat
Запускать так: ./pcat.sh input.txt
➡️ Теперь разбираемся:
threads указываем количество потоков для чтения текстового файла.
process_line = функция, которая будет обрабатывать строку, у меня это простое echo, но можно накручивать любую логику.
export -f = экспортируем функцию, чтобы функция была доступна в subprocess (этот момент ранее в постах мы с тобой уже разбирали, ссылку не дам, по поиску найдешь если интересно).
fifo = задействуем FIFO для контроля потоков (чуть ниже объясню что это такое за хуйня).
mkfifo = создаём именованный канал /tmp/fifo для контроля количества одновременно запущенных потоков.
for ((i = 0; = заполняем каналы «семафора» чтобы ограничить потоки.
while IFS = читаем файл построчно и обрабатываем строки.
read -u 3 = ждем свободный слот «семафора», каждый поток блокируется до тех пор, пока не освободится место в «семафоре».
wait exec 3>&- = ждем завершение всех потоков
Что такое FIFO?
FIFO = «первым пришёл — первым ушёл».Представляем ебейшую очередь в магазине: 1. Бабки встают в очередь 2. Первым обслуживают ту бабку, что пришла первой 3. Никто не может сказать — мне только спросить и пройти первым Ну или на примере стопки книг: Если ты складываешь книги в стопку и потом начинаешь снимать их, то ты будешь использовать LIFO (Last In, First Out). Но если ты встал в очередь к кассе — это FIFO. Думаю ты ты понял, тут все просто. Единственное отличие от
cat, у нас получилось, что строчки выводятся в порядке завершения потока. Какой поток быстрее завершился тот и папа.
строка4
строка1
строка2
строка3
строка5
строка6
С другой стороны эту поделку можно применить для каких-то задач, где порядок строк в файле неважен, ну или еще для чего-то.
Ну и домашка тебе: сделай так, чтобы строчки выводились по порядку (также, как и в файле), но использовалась многопоточность.
Пользуйтесь, чо!
tags: #bash #linux
—
🔔 @bashdays➡️ @gitgatecat, но не все знают про tac.
Так, так, так… Чо это?
Этот тот же cat только Команда tac входит в состав пакета GNU coreutils, и, как правило, она предустановлена на большинстве Linux-дистрибутивов.Ща покажу. Есть у нас злой файл:
ножка на ножку и залупа в ладошку
eбутся утки вторые сутки
хуй сосали на вокзале
Запускаем:
tac file.txt
хуй сосали на вокзале
eбутся утки вторые сутки
ножка на ножку и залупа в ладошку
Поняли? Ну либо так:
echo -e "строка 1\nстрока 2\nстрока 3" | tac
строка 3
строка 2
строка 1
А можно прям разделитель указать:
echo "слово1:слово2" | tac -s ":"
слово2
слово1
Где применить?
Да где хочешь, можешь логи смотреть, можешь в bash скрипты пихать, можешь из csv бигдату собирать и т.п.
Такие дела, изучай!
tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgateSIGRTMIN+0 - SIGRTMIN+7 для передачи битов, SIGRTMIN+8 - признак окончания символа, SIGRTMIN+9 признак окончания сообщения).
Передаются только "единичные биты". SEND_CHAR - "разбирает символ по битам и передает" SEND_MESSAGE - разбирает сообщение по символам и отдает SEND_CHAR.
Сохраняем скрипты, chmod +x serv.sh cli.sh
В одном терминале ./serv.sh (он выдаст что-то вроде Listener process 340527).
В другом терминале ./cli.sh 340527 (нужно подставить ваш номер процесса).
При старте клиент сразу передает серверу сообщение "BashBays" А потом можете передать привет медведю. Пустое сообщение завершает клиента. Сервер останавливается через CTRL-C.
#/bin/bash
#serv.sh
declare -i ASC=0
declare MSG=
declare DELAY=0.01
handle_signal() {
case "$1" in
W) MSG=${MSG}$(printf "\x$(printf %x $ASC)")
ASC=0 ;;
M) echo $MSG;MSG=;;
*) ((ASC+=$1));;
esac
}
#RTMIN=34
trap 'handle_signal 1' RTMIN+0
trap 'handle_signal 2' RTMIN+1
trap 'handle_signal 4' RTMIN+2
trap 'handle_signal 8' RTMIN+3
trap 'handle_signal 16' RTMIN+4
trap 'handle_signal 32' RTMIN+5
trap 'handle_signal 64' RTMIN+6
trap 'handle_signal 128' RTMIN+7
trap 'handle_signal W' RTMIN+8
trap 'handle_signal M' RTMIN+9
echo Listener process $$
while :;do
sleep $DELAY
done
#!/bin/bash
#cli.sh
if [[ -z $1 ]];then
echo Need server PID
exit
fi
declare -ir SERV_PID=$1
declare MESSAGE=BashBays
declare -ir RTM=34
function DELAY(){ sleep 0.02;}
function SEND_CHAR(){
local -i i ASC
CUR_CHAR=${1:-" "}
printf -v ASC "%d" "'$CUR_CHAR"
for i in {0..7};do
if [[ $(($ASC%2)) -eq 1 ]];then
# echo kill '-'$(($i+$RTM)) $SERV_PID
kill '-'$(($i+$RTM)) $SERV_PID
DELAY
fi
((ASC/=2))
done
# echo kill '-'$((8+$RTM)) $SERV_PID
kill '-'$((8+$RTM)) $SERV_PID
DELAY
}
function SEND_MESSAGE(){
local CUR_CHAR
local MESSAGE=${1:-BashDays}
local i
echo Send message \"$MESSAGE\" to Server PID=$SERV_PID
for ((i = 0 ; i < ${#MESSAGE} ; i++));do
SEND_CHAR ${MESSAGE:$i:1}
done
# echo kill '-'$((9+$RTM)) $SERV_PID
kill '-'$((9+$RTM)) $SERV_PID
DELAY
}
while [[ $MESSAGE ]];do
SEND_MESSAGE "$MESSAGE"
read -p "Input new message:" MESSAGE
done
Для чего может пригодиться эта фигня я не знаю, Но при написании программы выяснил некоторые вещи:
1. Обработка сигналов (по крайней мере SIGRTMIN не прерывает выполнение команд bash). Т.е если выполняется sleep 10m. То обработки можно ждать долго.
2. Обратите внимания на задержки в программах. На сервере ввел задержку, чтобы не сильно грузить процессор, на клиенте задержка больше, чем на сервере, иначе сигналы могут теряться. Кому интересно - можете поиграться.
tags: #linux © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgatevlock.
Устанавливается так: apt install vlock
Vlock блокирует виртуальную консоль/ли и требует ввода пароля.
Короче сидишь ты такой, на ascii картинки рукоблудишь в терминале, заходит мамка и ты такой — vlock бля!
Консоль моментально превращается в сообщение — This TTY is now locked. Please press [ENTER] to unlock.
Вот и всё! Это типа WIN+L или как там на маках CMD+CTRL+Q, но только для консоли. Локскрин! На случай если у тебя иксов нет, или ты в серверной живешь.
А чем отличается консоль от терминала я писал в этом посте и да, это не одно и тоже!Чо там этот
vlock умеет?
Основное:
-c lock only this virtual console, allowing user to switch to other virtual consoles. -a lock all virtual consoles by preventing other users from switching virtual consoles. -n allocate a new virtual console before locking,implies --all. -s disable SysRq while consoles are locked to prevent killing vlock with SAK -t run screen saver plugins after the given amount of time.🅰️🅰️ Из сочного тут -s отключает сочетания клавиш SysRq, лично не проверял, но будем верить что если на заборе написано — хуй, значит он там есть. 🅰️🅰️
Про Magic SysRq писал тут, обязательно почитай, тема довольно пиздата.А еще прикол обнаружил в
vlock, что если у тебя авторизация (аутентификация) по ключам, то пароль от юзера или рута ты никогда не вспомнишь. Аксиома!
Ну и получается разблокировать сеанс уже никак не сможешь. Поэтому с этим поаккуратнее, сначала вспоминай пароли и лишь только потом запускай этот скринлокер.
ХЗ кто этой байдой пользуется, но она существует и о ней порой говорят в англоязычном сегменте.
Короче я показал, ты почитал. На этом и закончим. Мож где-то пригодится. Давай краба!
tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgateЗадача: у меня есть серверный процесс, который должен получить уведомление от клиента с некоторыми данными (например, номер задачи). Вместо передачи данных через файлы или другие средства, нужно использовать сигналы реального времени.Сначала будет нихуя не понятно, но под конец я тебе всё разжую. Не переживай, тут все просто. Поймешь суть, сможешь реализовать на любом языке программирования. Пишем сервер signal_listener.sh
#!/bin/bash
handle_signal() {
echo "Получен сигнал $1"
echo "Переданные данные: $2"
}
trap 'handle_signal SIGRTMIN+0 "Task 1 выполнена"' RTMIN+0
trap 'handle_signal SIGRTMIN+1 "Task 2 выполнена"' RTMIN+1
echo "Слушатель запущен. PID: $$"
echo "Ожидаем сигналы..."
while true; do
sleep 1
done
Пишем клиент signal_sender.sh
#!/bin/bash
if [ $# -ne 2 ]; then
echo "Использование: $0 <PID> <TASK>"
echo "TASK может быть 1 или 2"
exit 1
fi
PID=$1
TASK=$2
if [ "$TASK" -eq 1 ]; then
kill -RTMIN+0 $PID
echo "Отправлен сигнал SIGRTMIN+0 (Task 1) процессу с PID $PID"
elif [ "$TASK" -eq 2 ]; then
kill -RTMIN+1 $PID
echo "Отправлен сигнал SIGRTMIN+1 (Task 2) процессу с PID $PID"
else
echo "Ошибка: TASK должен быть 1 или 2"
exit 1
fi
trap = перехватываем сигналы, для СРВ пишем: RTMIN+0 и RTMIN+1
kill -RTMIN+N = отправляет СРВ. Номер сигнала (например, RTMIN+0) задаёт, какой именно сигнал будет обработан.
chmod +x signal_listener.sh signal_sender.sh
Запускаем первый скрипт, видим его PID:
Слушатель запущен. PID: 20821
Во втором терминале запускаем второй скрипт:
./signal_sender.sh 20821 1
Отправлен сигнал SIGRTMIN+0 (Task 1) процессу с PID 20821
Не забываем подставить PID, который выдал первый скрипт.
После отправки СРВ, в терминале где запускали первый скрипт видим:
Получен сигнал SIGRTMIN+0
Переданные данные: Task 1 выполнена
Вот это нихуя се! То есть signal_sender подключился к процессу 20821 и передал в него данные.
В нашем случае данные это 1 или 2. А скрипт signal_listener успешно это схавал и переварил исходя из логики.
Использование СРВ открывает ОГРОМНЫЕ возможности, чтобы несколько скриптов или приложений взаимодействовали друг с другом на низких уровнях не использую велосипеды и прокладки.А когда какой сигнал использовать? Хе… 34-64… Если у тебя не сложная логика, можешь использовать любой индекс в этом диапазоне. Но если логика совсем ебанутая, то логичнее использовать СРВ с разными индексами для передачи данных. Например, тебе нужно обрабатывать разные типа событий. В этом случае проще разделить их на разные сигналы. Типа такого:
SIGRTMIN+0 (34): "Начать обработку данных"
SIGRTMIN+1 (35): "Обновить конфигурацию"
SIGRTMIN+2 (36): "Выебать медведя в жопу"
SIGRTMIN+3 (37): "Остановить обработку данных"
Это избавляет от необходимости декодировать данные внутри обработчика, потому что обработка сразу зависит от типа сигнала.
А можно обрабатывать в порядке приоритета. СРВ обрабатываются в порядке их номеров (от SIGRTMIN к SIGRTMAX). Это заебись если у тебя задачи с разным приоритетом.
SIGRTMIN+0: Высший приоритет (аварийная задача)
SIGRTMIN+1: Средний приоритет (регулярные уведомления)
SIGRTMIN+2: Низший приоритет (обновление статистики)
Если сигналы поступают одновременно, сначала обработается SIGRTMIN+0, потом SIGRTMIN+1 и т.д.
Важно! Использование одного СРВ может привести к переполнению и перезаписи очереди. Имей это ввиду. Потому, что с этим часто ловят багу и потом неделю не могут понять в чем причина. Иногда пишут что СРВ не теряются, но практика показывает обратное.
Если что-то еще вспомню, накидаю отдельным постом.
Удачи тебе и береги себя!
про сигналы писал ранее тут и тут и тут и тутtags: #linux — 🔔 @bashdays➡️ @gitgate
kill -l.
И куда же блядь эти сигналы делись?
А всё просто, сигналы с номерами 32 и 33 в современных линукс дистрибутивах зарезервированы для использования библиотекой glibc. И используются для реализации механизма потоков (threads).
Исходник glibc где он резервирует эти сигналы. Можешь увидеть что они будут не обязательно 32 и 33.
22 static int current_rtmin = __SIGRTMIN + 2;
23 static int current_rtmax = __SIGRTMAX;
Один из сигналов может быть использован для внутренних коммуникаций между потоками. Второй может служить для управления потоками на уровне ядра.
Сигналы же начинающиеся с номера 34 называются — сигналами реального времени. Более подробно про сигналы реального времени можешь почитать тут.
Если попытаться отправить сигнал 32 или 33 вручную процессу, то получишь хуй с маслом. Ядро эти сигналы обрабатывать не будет.
Потому что даже ядро не имеет к этим сигналам никакого отношения. А вмешиваться в потоки glibc тебе никто не даст, чтобы ты письку себе случайно не оторвал.
kill -32 10929
Unknown signal 32
Чтобы убедиться что сигнал 32 и 33 не являются сигналами реального времени, можно написать такой тест:
#include <stdio.h>
#include <signal.h>
int main() {
printf("SIGRTMIN: %d\n", SIGRTMIN);
printf("SIGRTMAX: %d\n", SIGRTMAX);
return 0;
}
Скомпилировать и запустить:
gcc -o signals signals.c
./signals
В ответ ты получишь что-то подобное:
SIGRTMIN: 34
SIGRTMAX: 64
Test Passed! Сигналы реального времени начинаются с 34. Но опять же не факт, что в твоём дистрибутиве будет так же. Мож ты всё еще на Slackware сидишь.
А нахуя нужны сигналы реального времени?
Давай лучше завтра, сегодня мы разбирались куда делись сигналы 32 и 33. Не хочу раздувать этот пост и пугать тебя раньше времени СИськастым кодом.
Увидимся!
про сигналы писал ранее тут и тут и тутtags: #linux — 🔔 @bashdays➡️ @gitgate
sata hdd wd-blue 1Tb (WD10EZEX)=1 ошибка на 1E14 бит sata hdd wd-gold 1 Tb(WD1005FBYZ)=1 ошибка на 1E15 бит sas hdd Toshiba 900 Гб (AL15SEB090N) 10 ошибок на 1E17 бит sata ssd Micron 960 Гб (MTFDDAK960TDS-1AW1ZABYY)1 ошибка на 1E17битДанные брал с сайта одной компьютерной компании с синим логотипом, отличающейся классной технической грамотностью. Короче, вероятность считать битый шифрованный архив с WD-GOLD в 10 раз меньше, чем с WD-BLUE и в 100 раз c Toshiba, и в 1000 раз меньше с ssd Micron. Хочу так же обратить внимание на Проникновение долбанных маркетологов Toshiba в тех. описание. 10 ошибок на 1E17 бит РАВНО 1 ошибок на 1E16 бит. А еще, приличные производители sas-дисков честно говорят о зафиксированных ошибках. Информацию можно глянуть командой из пакета smartmontools
sudo smartctl -a /dev/sdXX
#смотреть после Error
Конечно, для хранения можно использовать и wd-blue, но только с применением специальных файловых систем с контрольными суммами, или применением форматов хранения файлов с избыточностью (типа платный rar).
Кстати, не все рейды справятся с такой ошибкой. Большинство рейдов (0,1,5,10) защищают от поломки диска, но не от неправильного чтения.
6 - вроде бы считает контрольные суммы для каждой записи и корректирует, если что (поправьте если не прав).
Ну, и рейдовые zfs решают проблемы, поскольку содержат контрольные суммы файлов.
В комментах было бы интересно почитать, кто какие диски использует и какие меры применяет, чтобы считывать именно ту информацию, которую записываешь.
tags: #hardware © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgate
متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
