Есть такие команды, они выведут справку по утилите printf:
НО. Каждая команда выведет свою версию справки (почти). То есть результат вывода будет отличаться в разных случаях. Не веришь? Попробуй сам.
В первом пункте с help printf всё понятно. Получишь некий огрызок, который трудно назвать страницей помощи. Да и во втором тоже самое.
В 1-2 вызывается именно встроенная утилита printf в оболочку Bash. А вот в третьем пункте, выведется достаточно внушительный хелп.
И этот внушительный хелп будет от схожей, внешней утилиты printf, которая располагается тут: /usr/bin/printf.
Посмотреть все варианты printf можно так:
На экран выведется список:
Ну и везде советуют пользоваться встроенной в Bash командой help, она нативнее и поддерживает почти весь синтаксис оболочки. Тут уже решать тебе.
Я очень редко читаю документацию таким способом, предпочитаю сразу загуглить. Ладно. Изучай.
tags: #bash
—
@BASHDAYS
1. 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
Привет, я тут немного затроил, но без чтива вас не оставлю. Сегодня обсудим что делает kill -0 $pid в Bash скриптах.
В принципе логично, команда должна убить какой-то процесс. Но как мы знаем, сигналы начинаются с единицы (1) = SIGHUP, а тут какой-то странный нолик затесался.
Что забавно, в официальной документации и всяких манах информации по этому нулю очень мало.
В некоторых дистрибутивах, через man 2 kill можно получить такой ответ:
If sig is 0, then no signal is sent, but existence and permission checks are still performed; this can be used to check for the existence of a process ID or process group ID that the caller is permitted to signal.
Не по-русски, но с переводчиком понятно. Короче с помощью нуля, можно проверить запущен ли процесс и может ли пользователь отправлять ему сигналы.
Давай к примерам:
1. Запускаем в фоне задачу sleep
2. Присваиваем переменной PID процесса
3. Проверяем, если процесс с $pid запущен, то убиваем его
4. Проверяем что процесс убит
Здесь мы с помощью нуля проверили наличие запущенного процесса и на возможность отправлять ему сигналы. Если всё ок, то отрабатывает команда kill $pid.
А если запустить так:
Получим статус выхода. То есть процесс не запущен и можно смело выходить со статусом 1.
Ну и напоследок проверим, может ли пользователь отправлять сигналы процессы. Запускаем под обычным пользователем:
В итоге получим:
То есть запускаем фоновый процесс от рута, а затем с помощью нуля проверяем, сможет ли обычный пользователь убить этот процесс. Как видим - хуй, не сможет.
В нормальной жизни я редко встречал скрипты с такими конструкциями и проверками, но тот кто профессионально пишет для opensource это прям мастхев, суют везде, мама не горюй.
Хорошего дня, а я пошел дальше диван давить, да лечиться. Увидимся!
tags: #bash
—
@BASHDAYS
В принципе логично, команда должна убить какой-то процесс. Но как мы знаем, сигналы начинаются с единицы (1) = SIGHUP, а тут какой-то странный нолик затесался.
Что забавно, в официальной документации и всяких манах информации по этому нулю очень мало.
В некоторых дистрибутивах, через man 2 kill можно получить такой ответ:
If sig is 0, then no signal is sent, but existence and permission checks are still performed; this can be used to check for the existence of a process ID or process group ID that the caller is permitted to signal.
Не по-русски, но с переводчиком понятно. Короче с помощью нуля, можно проверить запущен ли процесс и может ли пользователь отправлять ему сигналы.
Более подробно про сигналы я писал в этом посте
Давай к примерам:
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
—
@BASHDAYS
In your head, in your head, Zombie, zombie, zombie-ie-ie…
Привет. Вчера Юра в комментах спросил за зомби процессы и как с ними деликатно обходиться. Расскажу про свой не деликатный опыт. Поехали.
Что такое зомби-процессы?
Всё, с теорий хватит. Чтобы потыкать палкой какой-нибудь зомби процесс, нужно его искусственно создать. Пишем на СИ портянку (ниже будет и на Bash):
Этот код создает дочерний процесс, который сразу же завершается. Родительский процесс ждет 2 часа и затем завершается без вызова wait(). Вот так мы и получим своего маленького зомби, над которым будем ставить эксперименты.
Компилируем и запускаем в фоне этого зомбаря:
Либо создаем зомби через Bash:
Выполняем команды и наблюдаем zombie процесс:
Вывод на экран:
Ага, хорошо, зомби завели. Теперь как это дело всё закилить. Простой kill -9 PID не поможет, так как PID родительского процесса будет отличаться от дочернего.
Чтобы найти PID родителя, смотрим:
Кто-то грепает по слову defunct, тут уже по потребностям выбирай.
Видим все PIDы и родителя и дочернего:
В моем случае PID родительского = 1669050, а дочернего 1669051, который собственно и есть зомбик.
Теперь накидываем однострочник:
Эта штука найдет все зомби процессы и уничтожит их. Даже не нужно никакие циклы на Bash колхозить.
А если требуется регулярно зачищать зомборей, вешаем однострочник на cron и радуемся.
Вообще это самый простой способ закилить эту каку. Как это сделать через gdb напишу на следующей неделе. Но сразу предупреждают, там оверхед решение и скорее всего оно тебе не понравится. Хотя через gdb можно оставить в живых родительский процесс и убить только дочерних зомбаков.
У меня зомбаки порой случались с nginx на древней CentOS, но после апгрейда на убунту, все прошло.
Если сможешь что-то еще добавить, пиши в комменты, будет всем полезно.
Давай, хороших выходных, не болей!
tags: #bash #linux
—
@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 -o stat,ppid | grep -e '[zZ]'| awk '{ print $2 }')
Эта штука найдет все зомби процессы и уничтожит их. Даже не нужно никакие циклы на Bash колхозить.
А если требуется регулярно зачищать зомборей, вешаем однострочник на cron и радуемся.
Вообще это самый простой способ закилить эту каку. Как это сделать через gdb напишу на следующей неделе. Но сразу предупреждают, там оверхед решение и скорее всего оно тебе не понравится. Хотя через gdb можно оставить в живых родительский процесс и убить только дочерних зомбаков.
В большинстве случаев не стоит обращать внимание на этих зомбаков, эти процессы не жрут ресурсы, а являются лишь косяками программного обеспечения.
У меня зомбаки порой случались с nginx на древней CentOS, но после апгрейда на убунту, все прошло.
Если сможешь что-то еще добавить, пиши в комменты, будет всем полезно.
Давай, хороших выходных, не болей!
tags: #bash #linux
—
@BASHDAYS
Начинаем утреннюю гимнастику!
Привет, эхх… люблю я издеваться над студентами, в хорошем смысле слова. Поэтому в арсенале всегда имеются задачки со звездочками. Типа с повышенной сложностью.
Задачи без хуйни, но с элементом соревнований. Как сейчас модно говорить — челендж. Так намного интереснее, это вызывает азарт. Обучение через геймификацию, все же топ штука.
Нужно написать самый короткий Bash скрипт, команду:
1. Вывести на экран таблицу умножения
2. Вывести на экран шахматную доску
Ниже я покажу самые короткие решения, которые меня порадовали. Авторы этих решений, 16ти летние пацаны. Видимо мозги еще не убиты кубиками и всратым скрамом.
Чо по плюшкам
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
Привет, эхх… люблю я издеваться над студентами, в хорошем смысле слова. Поэтому в арсенале всегда имеются задачки со звездочками. Типа с повышенной сложностью.
Задачи без хуйни, но с элементом соревнований. Как сейчас модно говорить — челендж. Так намного интереснее, это вызывает азарт. Обучение через геймификацию, все же топ штука.
Нужно написать самый короткий Bash скрипт, команду:
1. Вывести на экран таблицу умножения
2. Вывести на экран шахматную доску
Ниже я покажу самые короткие решения, которые меня порадовали. Авторы этих решений, 16ти летние пацаны. Видимо мозги еще не убиты кубиками и всратым скрамом.
Перед тем как откроешь спойлера, попробуй сам решить эти задачки и закинуть свои наработки в комментарии. Чьи решения наберут больше реакций/лайков — получатпиздюдейприз.
Чо по плюшкам
1. Аналоговая шаурма/тортик/пиво/другое. Макс закинет тебе приятный бонус на РФ карточку.
2. Статус в чатике - воин дракона (ну или какой сам захочешь).
А вот и самые короткие решения от моих студентов. Я предварительно их сломал, копипаста не сработает. Сначала подумай и пофикси, приключений на пару минут.
В комментах закинул скриншоты с рабочих вариантов.
Таблица умножения
Шахматная доска
Дерзай, сегодня наверное еще увидимся. Хорошего тебе дня! А я побежал дальше graylog ковырять.
tags: #bash #linux #games
—
@BASHDAYS
Сделать через жопу, это лучше, чем не сделать совсем
Иногда требуется проверить поведение скрипта, когда на диске физически закончилось место. Но создавать огромный файл с нулями и забивать всё место — такое себе решение.
А как быть? Да всё просто, диск можно забить искусственно, не забивая его. Для этого существует такая поебень как:
При попытке записи в
Это удобно для тестирования софта и обработчиков исключений. Например, пишет твой скрипт в файл какую-нибудь суету, место закончилось. Что будет дальше делать скрипт? Как он себя поведет?
Держу пари, будет пытаться продолжать писать. А по-хорошему, он должен сообщить тебе про это, либо корректно завершиться и освободить файл. Смекаешь?
Вот пример скрипта:
Скрипт при каждой итерации проверяет заполнен ли диск и если заполнен то выводит сообщение «Disk is full!».
Символ «!» в этом примере = инвертирует результат выполнения команды. То есть если запись в
Echo можешь заменить например на триггер, который тюкнет тебе в телеграм и скажет, что твой скрипт сожрал всё место.
Такие дела. Изучай.
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
Всегда задавай себе вопрос — а не хуйню ли я делаю?
Кринжатину давно не постил. Исправляюсь. А ты знал… хотя нет, скорее всего не знал. Короче если к слову «Linux» применить XOR шифрование с маской 28, то получится слово PURID = «Чистый».
Смотри:
Сразу пример, туда-обратно. Что тут происходит? Если кратно — происходят вычисления.
Для слова «Linux» в фигурных скобках применяется Bash Brace Expansion, который приводит слово к такому виду:
Арифметическое действие происходит в «$[». А решетка + 64 означает, что числа будут интерпретированы как шестидесятеричные (в системе счисления по основанию 64).
В итоге получаем число, которое будет вычислено как комбинация ASCII-кодов символов
Ну и echo -e = разрешаем интерпретацию escape-последовательностей в строке.
Кринжатина? Еще какая! А сейчас давай оверхед на perl:
Где это можно применить, понятия не имею. Возможно это как-то натолкнет тебя на правильные мысли и ты решишь изучить методы шифрования.
Ладно, не смею больше насиловать твой чистый разум. Изучай!
tags: #bash #linux
—
@BASHDAYS
Кринжатину давно не постил. Исправляюсь. А ты знал… хотя нет, скорее всего не знал. Короче если к слову «Linux» применить XOR шифрование с маской 28, то получится слово PURID = «Чистый».
Это как если к слову «хлеб» применить 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
0xB105F00D, 0xB16B00B5, 0x0B00B135, 0xDEADBABE
И снова здрасти. Сегодня на изи, работы валом.
Короче эти штуки сверху называются HexSpeak. Это не просто HEX смещение, это запись английский слов, с помощью чисел в шестнадцатеричной системе счисления.
Такой вот отголосок из 80х, когда была сцена, демки в 4кб и т.п. Многие персонажи, делали себе подобные ники:
Да чо далеко ходить, вон в исходных кодах полноэтого говна магических чисел с этими хекспиками. Да и в пасхалки порой их суют.
Кто всю эту тему раскачал хуй знает, видимо народное творчество.
Смысл ты наверное понял, как все это кодируется. Но вкратце: символ «0 - ноль» может быть буквой «О», а «1» = «L» или «I» ну и т.д.
Короче это гиковская культура.
Теперь смотрим на картинку к посту. Если открыть JAVA файл c классом в редакторе, его первая строка будет выглядеть как «cafe babe». Первые четыре байта. Это магическое число используется для идентификации классов JAVA.
А почему вообще «cаfe babe»? На самом деле предположений много разных. Но позже Джеймс Гослинг (батя JAVA) все прояснил. Они вечно тусовались в кофейне, которое прозвали «CAFE DEAD». На самом деле там длинная история, погуглите.
Ну и вот, в процессе работы Джеймсу понадобилось заебенить магическое число, а «CAFE DEAD» как раз представляло шестнадцатеричное число. Ну и он его запихал для формата объектного файла. Короче ничо специально не делалось, все произошло в моменте.
Про популярные комбинации хекспиков, можешь глянуть на википедии.
Давай, завтра увидимся, а на выходные уж отдохнем.
tags: #linux
—
@BASHDAYS
И снова здрасти. Сегодня на изи, работы валом.
Короче эти штуки сверху называются HexSpeak. Это не просто HEX смещение, это запись английский слов, с помощью чисел в шестнадцатеричной системе счисления.
Такой вот отголосок из 80х, когда была сцена, демки в 4кб и т.п. Многие персонажи, делали себе подобные ники:
B105F00D = 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
Не бей себя ушами по щекам!
Вопрос который я задаю на собесах, возможно с подвохом. Частенько ставит в ступор соискателей. Короче.
Есть два бесконечных bash цикла:
И тут начинается… у людей включается javascript мышление и они начинают троить. Раз есть задача, значит есть и разница в поведении, значит будут какие-то разные ожидаемые результаты.
Рисуют мне какие-то формулы, строят гипотезы, даже пытаются доказать свою правоту и послать меня на хуй.
Ведь как происходит, пишешь ты годами bash скрипты и даже не задумываешься, а схренали я использую «:» а не «true»? Да потому что оно нахер не всралось про это думать, работает и ок.
На самом деле эти циклы делаю одно и тоже. Объяснение простое:
Команда «:» всегда возвращает 0. Да «:» это команда, попробуй её запустить, а следом выполнить
Эта пустая команда, которая ничего не делает и всегда завершается успехом. Ее используют, там где в синтаксисе скрипта требуется какая-либо команда.
Для while справедливо требуется продолжение, вот мы и продолжаем с помощью «:» чтобы интерпретатор не засыпал ошибками. Этакая заглушка, для синтаксической корректности.
Ну а так как true тоже команда и всегда возвращает статус 0, получается что «:» и true = идентичны. Просто написать двоеточие намного быстрее.
Ноги растут из древних Bourne Shell, где не было встроенных команд ни true ни false. Использовали именно «:».
Получается «:» легаси? Ну можно и так сказать. Если хочешь чтобы твои скрипты работали в древних оболочках, используй «:». А если похер, то делай true.
Вот что лучше читается?
Мне очевиднее первый вариант, если не знать за «:», то словишь ступор. Такие дела. Изучай.
tags: #linux #bash
—
@BASHDAYS
Вопрос который я задаю на собесах, возможно с подвохом. Частенько ставит в ступор соискателей. Короче.
Есть два бесконечных bash цикла:
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
Если ты относишь себя к девопс-инженеру или что-то в этом духе — никогда не используй панельки ISPManager/VestaCP и т.п. для настройки серверов.
Привет. Короче сторис.
День первый.
100 лет назад я устроился в свою первую, местную веб-студию и велком таска на испытательном сроке была — подготовить сервер для клиентского проекта.
Нет, меня не закинули в озеро с крокодилами, мне дали инструкцию, как все это дело настроить. Но проблема была в том, что вся настройка сводилась к работе в чистой консоли.
В то время я уже был уверенный джун, но никогда не настраивал сервера таким способом, для меня это было — дичь ебаная!
На изучение мне понадобилась бы неделя, но обосраться с первой задачей я не мог. Но естественно обосрался.
Уже тогда, моя хитрожопость не знала границ. У меня был доступ в панель управления хостинга. И что я сделал? Правильно, пересоздал сервер с готовой Free ISPМ панелькой.
Ну а дальше по накатанной, мышкой натыкал за полчаса, домены прописал, пехапе и апачу (фу-фу) завел. Таску в done двинул. Сижу радуюсь, какой же я охуенный!
Потратил полчаса на таску, на которую мне выделили 8 часов. Естественно остальное время я пропинал хуи.
День второй.
На следующий день состоялся релиз клиентского проекта. Но… деплой не прошел, jenkins высрал еррор, мол — пермишен денаед.
И понеслась пизда по кочкам. Шеф вызвал на ковер и задал свой любимый вопрос — как такое произошло? Я долго что-то мямлил, ну и каким-то чудом всё вскрылось.
Как оказалось, инструкция по которой мне дали настраивать сервак, была отлажена годами и под эту настройку был заточен jenkins. Разработчик просто указывал IP адрес сервера куда выкатить вонючий битрикс и оно выкатывалось.
В моём случае, на серваке банально не были прописаны ssh ключи этого злоебучего jenkins’а. Нууу…. и не хватало структуры каталогов, заведенных пользователей, нехватало — ничего! Короче ЖОПА!
Ну я же не знал… Хотя мне потом все красиво объяснили, что я лось дырявый. И что нужно делать все по ТЗ, а не как мне оленю захочется. Процессы, все дела.
Короче пиздов отхватил знатно, а задачу вернули на доработку. С тех пор, я научился придерживаться условиям задачи. Ну и самое главное нехило так качнул свои знания в Linux. Правда на всё про всё ушла неделя.
Позже я накидал bash скрипт, который сам настраивал сервера по шаблону за несколько минут. Опыт дал о себе знать. Про этот скрипт я никому не говорил, хитрожопость.
Шеф был тот еще мудень, но его доёбки до любых мелочей выстроили в моей башке правильные нейронные связи.
Потом этот шеф написал на меня заяву, якобы я ему бекдоров насувал после увольнения. Но это были не бекдоры, а его дырявые битрикс. Короче разошлись мирно. Через несколько лет я узнал, что он много на кого бочку катил, обижался если от него уходили.
Сейчас, когда я умею с закрытыми глазами настраивать чёрта через консоль, я могу позволить себе панельки ISPM/VESTA, потому что понимаю что там под капотом и как это работает. Но в 99% предпочитаю консольку. Олдскулл.
Такие дела.
Всегда иди туда, где страшно. Чем страшнее, тем больше опыта получишь. А используя панельки, ты остаешься на уровне овоща, никакого развития. Понятно дело, оно проще, быстрее, но минус значительный — деградируешь.
У меня кореш активно пользуется панельками, но он не позиционирует себя как девопс, ему этот опыт нахер не нужен, ему нужно рабочее окружение под вордпресс и его пет-проекты.
Ладно, давай, хорошей тебе недели и не будь овощем!
tags: #рабочиебудни
@BASHDAYS
Привет. Короче сторис.
День первый.
100 лет назад я устроился в свою первую, местную веб-студию и велком таска на испытательном сроке была — подготовить сервер для клиентского проекта.
Нет, меня не закинули в озеро с крокодилами, мне дали инструкцию, как все это дело настроить. Но проблема была в том, что вся настройка сводилась к работе в чистой консоли.
В то время я уже был уверенный джун, но никогда не настраивал сервера таким способом, для меня это было — дичь ебаная!
На изучение мне понадобилась бы неделя, но обосраться с первой задачей я не мог. Но естественно обосрался.
Уже тогда, моя хитрожопость не знала границ. У меня был доступ в панель управления хостинга. И что я сделал? Правильно, пересоздал сервер с готовой Free ISPМ панелькой.
Ну а дальше по накатанной, мышкой натыкал за полчаса, домены прописал, пехапе и апачу (фу-фу) завел. Таску в done двинул. Сижу радуюсь, какой же я охуенный!
Потратил полчаса на таску, на которую мне выделили 8 часов. Естественно остальное время я пропинал хуи.
День второй.
На следующий день состоялся релиз клиентского проекта. Но… деплой не прошел, jenkins высрал еррор, мол — пермишен денаед.
И понеслась пизда по кочкам. Шеф вызвал на ковер и задал свой любимый вопрос — как такое произошло? Я долго что-то мямлил, ну и каким-то чудом всё вскрылось.
Как оказалось, инструкция по которой мне дали настраивать сервак, была отлажена годами и под эту настройку был заточен jenkins. Разработчик просто указывал IP адрес сервера куда выкатить вонючий битрикс и оно выкатывалось.
В моём случае, на серваке банально не были прописаны ssh ключи этого злоебучего jenkins’а. Нууу…. и не хватало структуры каталогов, заведенных пользователей, нехватало — ничего! Короче ЖОПА!
Ну я же не знал… Хотя мне потом все красиво объяснили, что я лось дырявый. И что нужно делать все по ТЗ, а не как мне оленю захочется. Процессы, все дела.
Короче пиздов отхватил знатно, а задачу вернули на доработку. С тех пор, я научился придерживаться условиям задачи. Ну и самое главное нехило так качнул свои знания в Linux. Правда на всё про всё ушла неделя.
Позже я накидал bash скрипт, который сам настраивал сервера по шаблону за несколько минут. Опыт дал о себе знать. Про этот скрипт я никому не говорил, хитрожопость.
Шеф был тот еще мудень, но его доёбки до любых мелочей выстроили в моей башке правильные нейронные связи.
Потом этот шеф написал на меня заяву, якобы я ему бекдоров насувал после увольнения. Но это были не бекдоры, а его дырявые битрикс. Короче разошлись мирно. Через несколько лет я узнал, что он много на кого бочку катил, обижался если от него уходили.
Сейчас, когда я умею с закрытыми глазами настраивать чёрта через консоль, я могу позволить себе панельки ISPM/VESTA, потому что понимаю что там под капотом и как это работает. Но в 99% предпочитаю консольку. Олдскулл.
Такие дела.
Всегда иди туда, где страшно. Чем страшнее, тем больше опыта получишь. А используя панельки, ты остаешься на уровне овоща, никакого развития. Понятно дело, оно проще, быстрее, но минус значительный — деградируешь.
У меня кореш активно пользуется панельками, но он не позиционирует себя как девопс, ему этот опыт нахер не нужен, ему нужно рабочее окружение под вордпресс и его пет-проекты.
Ладно, давай, хорошей тебе недели и не будь овощем!
tags: #рабочиебудни
@BASHDAYS
Про шлюх и CodeFest
Привет, хотел про рабочие будни, падших женщин и CodeFest рассказать, но это скучно. Как-нибудь в другой раз.
А сегодня рассмотрим интересную команду —
С помощью compgen можно вывести список всех консольных команд, которые вообще доступны в твоём Linux дистрибутиве.
✔️ Запускаем:
И наблюдаем. Да, это полный список команд, мне выплюнуло аж 3490. Поверь там ОЧЕНЬ много интересного.
✔️ Секрет успеха
Выгружаем все это в файл и каждый день изучаем по три-пять команд из этого списка.
А через месяц ты настолько преисполнишься в своем сознании, что аж пиздец. Я на полном серьезе!
Кстати по аналогии, я каждый день читаю по 10-20 слов из словаря Ожегова. Отлично расширяет словарный запас. Рекомендую.
У
-a = выведет список алиасов
-b = список всех bash модулей
-k = вывод ключевых слов
-A function = вывод всех функций
Ладно, что еще можно с compgen сделать:
✔️ Генерация списков
На экран выведется список файлов в текущем каталоге.
✔️ Анализ окружения
Выведется весь список переменных окружения.
✔️ Генерация динамических списков
Скрипт динамически создаст список всех пользователей в Linux.
Еще есть прикол с автодополнением, но работает через жопу, поэтому нахер его. У нас тут только рабочая годнота.
Ну и вот. Пойду дальше диван давить, изучай. Увидимся!
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
Привет, хотел про рабочие будни, падших женщин и CodeFest рассказать, но это скучно. Как-нибудь в другой раз.
А сегодня рассмотрим интересную команду —
compgen
.С помощью compgen можно вывести список всех консольных команд, которые вообще доступны в твоём Linux дистрибутиве.
compgen -c
И наблюдаем. Да, это полный список команд, мне выплюнуло аж 3490. Поверь там ОЧЕНЬ много интересного.
Выгружаем все это в файл и каждый день изучаем по три-пять команд из этого списка.
А через месяц ты настолько преисполнишься в своем сознании, что аж пиздец. Я на полном серьезе!
Кстати по аналогии, я каждый день читаю по 10-20 слов из словаря Ожегова. Отлично расширяет словарный запас. Рекомендую.
У
compgen
есть еще масса ключей, некоторые из них:-a = выведет список алиасов
-b = список всех bash модулей
-k = вывод ключевых слов
-A function = вывод всех функций
Ладно, что еще можно с compgen сделать:
files=( $(compgen -f) )
echo "${files[@]}"
На экран выведется список файлов в текущем каталоге.
variables=( $(compgen -v) )
echo "${variables[@]}"
Выведется весь список переменных окружения.
users=( $(compgen -u) )
echo "${users[@]}"
Скрипт динамически создаст список всех пользователей в Linux.
Еще есть прикол с автодополнением, но работает через жопу, поэтому нахер его. У нас тут только рабочая годнота.
Обычно compgen используется в скриптах или в интерактивном режиме для быстрого доступа к определенным типам данных, доступных в текущем контексте оболочки.
Ну и вот. Пойду дальше диван давить, изучай. Увидимся!
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Если пишешь говнокод, неважно куда он попадет, в GIT репозиторий или унитаз. Суть одна.
Привет отдыхающим. Нашел на github неплохую пепяку «config-file-validator», которая из консольки валидирует файлы в форматах:
Работает на всём, линуксы, винда, макоська, малина. Надо только установить. В репах увы её нет. Написано на golang.
✔️ Репа с рейтингом, люди пользуются, форкают.
Я качнул с репозитория zip’ник и закинул в
А если любишь docker, то можно прям контейнер подтянуть с этим валидатором.
Теперь в каталоге с файлами запускаем: validator и смотрим:
Отличное решение, когда лень или нет возможности запускать IDE. Быстро, просто, бесплатно.
Люблю такие тулзы, вроде нихера не делают, но пользу приносят. Взял к себе на вооружение. Рекомендую.
🌐 Страница проекта на github
tags: #utils
@BАSHDАYS | BАSHDАYS.CОM
Привет отдыхающим. Нашел на github неплохую пепяку «config-file-validator», которая из консольки валидирует файлы в форматах:
Apple PList XML, CSV, ENV, HCL, HOCON, INI, JSON, Properties, TOML, XML, YAML
Работает на всём, линуксы, винда, макоська, малина. Надо только установить. В репах увы её нет. Написано на golang.
Я качнул с репозитория zip’ник и закинул в
/usr/local/sbin
cd /tmp
wget https://github.com/Boeing/config-file-validator/releases/download/v1.6.0/validator-v1.6.0-linux-amd64.tar.gz
tar -xf validator-v1.6.0-linux-amd64.tar.gz
mv validator /usr/local/sbin
А если любишь docker, то можно прям контейнер подтянуть с этим валидатором.
Теперь в каталоге с файлами запускаем: validator и смотрим:
root@dev:# validator
× bashdays.json
error: Error at line 3 column 2: invalid character '"' after object key:value pair
✓ bashdays.yml
Summary: 1 succeeded, 1 failed
Отличное решение, когда лень или нет возможности запускать IDE. Быстро, просто, бесплатно.
Люблю такие тулзы, вроде нихера не делают, но пользу приносят. Взял к себе на вооружение. Рекомендую.
tags: #utils
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
А у тебя спина белая!
Я раньше частенько баловался со всякими клавиатурными тренажерами. Ну знаете эти самые, которые разгоняют скорость печати. Все эти тренажеры, безумно душные и скучные.
Но я нашел вариант пизже. Называется ZType, только не оригинальный, а хакнутый с поддержкой Русского языка. На видео выше, сам можешь посмотреть.
Я загрузил в него тексты «Красной Плесени» и отправился в бой. Но есть варианты с текстами по умолчанию. Сука, это даже не тренажер, это шедевр. Затягивает основательно.
Помимо азарта, неплохо прокачивается скорость печати. Поиграй, не пожалеешь. Главное правило - во время игры не смотреть на клавиатуру.
✔️ Оригинальная версия
✔️ С поддержкой RU языка
tags: #games
@BАSHDАYS | BАSHDАYS.CОM
Я раньше частенько баловался со всякими клавиатурными тренажерами. Ну знаете эти самые, которые разгоняют скорость печати. Все эти тренажеры, безумно душные и скучные.
Самый лучший тренажер это конечно же VIM. Это аксиома.
Но я нашел вариант пизже. Называется ZType, только не оригинальный, а хакнутый с поддержкой Русского языка. На видео выше, сам можешь посмотреть.
Я загрузил в него тексты «Красной Плесени» и отправился в бой. Но есть варианты с текстами по умолчанию. Сука, это даже не тренажер, это шедевр. Затягивает основательно.
Помимо азарта, неплохо прокачивается скорость печати. Поиграй, не пожалеешь. Главное правило - во время игры не смотреть на клавиатуру.
tags: #games
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Мишки на сервере
Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.
Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!
А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.
Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇
✔️ https://t.me/bashday
Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.
Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.
Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!
А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.
Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇
Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.
Please open Telegram to view this post
VIEW IN TELEGRAM
У кого писька длиннее
Я порой нанимаю людей в штат для других компаний, в основном это девопс инженеры и SRE мальчики. 98% кандидатов это зажравшиеся морды, которые нихуя не умеют, но требуют 200-500к в месяц.
Хотя в резюме практически всегда написана тонна технологий, все сеньоры, куда деваться. Технические собеседования это хорошо, но я встречал 2х умельцев, которые подключали GPT и просто читали с экрана ответы. Ну хуйня же.
Поэтому пришлось сделать проще. Кандидат проходит техническое собеседование, даем оффер, испытательный срок 3 месяца, ЗП на старте ниже той, которую обсуждали. Заранее оговариваем этот момент с кандидатом. После испытательного ЗП вырастает на ту, что была указана в вакансии.
А дальше… а дальше цирк с конями. Я сделал второй мини продакшен из 5ти серверов (балансировщик, вебноды, базы, админки, демоны), подключил его к мониторингу, прикрутил домен. И позиционировал этот продакшен как основной.
Хотя на самом деле, это фейковый продакшен. Все запросы которые на него приходят, это просто дубли запросов с основного прода. Логи наполняются, траффик бежит, но по сути это просто затычка.
А теперь разъебон!
Спустя месяц испытательного срока, устраиваем диверсию этого фейкового продакшена. В пятницу вечером, за 15 минут до конца рабочего дня, чтобы мониторинг орал как сучка, чтобы все бегали с горящими жопами.
✔️ Самое главное повышать градус и писать в слак — ааа, все сломалось, когда почините? какие прогнозы?
Суть этой диверсии — посмотреть как будет реагировать инженер и как быстро он все это дело отремонтирует. Ну и если отремонтирует, то нужен отчет, где была проблема, как починил и как её избежать в будущем.
Скажу так, тест дай бог проходят 2-3 из 10 человек. Последние 2 кандидата спустя 4 часа дебага, сказали — мы не можем это починить, мы не знаем что это такое. А вот если бы мы знали, что это такое, мы бы починили. Умываем руки, чините сами.
Ну и нахуй такие сеньоры нужны? Вот упадет основной прод и чо? Мне самому его чинить чтоли? За что я плачу 500к?
Да и диверсия там простая, закрываем порты через iptables и балансировщик не может достучаться до других серверов. Ну либо файл с апстримами сносим, который можно забрать в корпоративном git репозитории.
По итогу все эти специалисты уходят по-собственному, так как не согласны жить в таком стрессе. Ну а как?
Возможно способ не гуманный, но эффективный, сразу на берегу видим, как человек поведет себя в критической ситуации и не сбежит ли поджав хвост.
На мне такие эксперименты не ставили, у меня обычно основной продакшен падал и пиздец. А там уже зависит от стержня, да, иногда мне хотелось убежать и заплакать.
Но я обычно беру паузу 10-15 минут, пусть полежит, может сам поднимется, это уже произошло, чо нервничать. А пока идут эти 10-15 минут, я спокойно накидываю идеи, куда я сейчас пойду и что проверю.
А потом иду и все поднимаю за пару минут. Главное всё делать с холодной головой. Чем больше суеты, тем больше потратишь времени на восстановление.
Пользуйтесь, отличный способ распознать оборотней, которые пиздят в резюме. Ну либо можете проводить учения если ваши девопсы заскучали, пусть разомнутся, им этого иногда не хватает.
Букв много получилось, но всё по делу. Давай, увидимся завтра.
tags: #рабочиебудни
@BАSHDАYS | BАSHDАYS.CОM
Я порой нанимаю людей в штат для других компаний, в основном это девопс инженеры и SRE мальчики. 98% кандидатов это зажравшиеся морды, которые нихуя не умеют, но требуют 200-500к в месяц.
Хотя в резюме практически всегда написана тонна технологий, все сеньоры, куда деваться. Технические собеседования это хорошо, но я встречал 2х умельцев, которые подключали GPT и просто читали с экрана ответы. Ну хуйня же.
Поэтому пришлось сделать проще. Кандидат проходит техническое собеседование, даем оффер, испытательный срок 3 месяца, ЗП на старте ниже той, которую обсуждали. Заранее оговариваем этот момент с кандидатом. После испытательного ЗП вырастает на ту, что была указана в вакансии.
А дальше… а дальше цирк с конями. Я сделал второй мини продакшен из 5ти серверов (балансировщик, вебноды, базы, админки, демоны), подключил его к мониторингу, прикрутил домен. И позиционировал этот продакшен как основной.
Хотя на самом деле, это фейковый продакшен. Все запросы которые на него приходят, это просто дубли запросов с основного прода. Логи наполняются, траффик бежит, но по сути это просто затычка.
А теперь разъебон!
Спустя месяц испытательного срока, устраиваем диверсию этого фейкового продакшена. В пятницу вечером, за 15 минут до конца рабочего дня, чтобы мониторинг орал как сучка, чтобы все бегали с горящими жопами.
Суть этой диверсии — посмотреть как будет реагировать инженер и как быстро он все это дело отремонтирует. Ну и если отремонтирует, то нужен отчет, где была проблема, как починил и как её избежать в будущем.
Скажу так, тест дай бог проходят 2-3 из 10 человек. Последние 2 кандидата спустя 4 часа дебага, сказали — мы не можем это починить, мы не знаем что это такое. А вот если бы мы знали, что это такое, мы бы починили. Умываем руки, чините сами.
Ну и нахуй такие сеньоры нужны? Вот упадет основной прод и чо? Мне самому его чинить чтоли? За что я плачу 500к?
Причем есть и документация к проектам и карта инфры + лог сервер + все что нужно, вникни и реши вопрос. Хули ты целый месяц делал?
Да и диверсия там простая, закрываем порты через iptables и балансировщик не может достучаться до других серверов. Ну либо файл с апстримами сносим, который можно забрать в корпоративном git репозитории.
По итогу все эти специалисты уходят по-собственному, так как не согласны жить в таком стрессе. Ну а как?
Айти это как бы про работу, а большие деньги это результат этой работы.
Возможно способ не гуманный, но эффективный, сразу на берегу видим, как человек поведет себя в критической ситуации и не сбежит ли поджав хвост.
На мне такие эксперименты не ставили, у меня обычно основной продакшен падал и пиздец. А там уже зависит от стержня, да, иногда мне хотелось убежать и заплакать.
Но я обычно беру паузу 10-15 минут, пусть полежит, может сам поднимется, это уже произошло, чо нервничать. А пока идут эти 10-15 минут, я спокойно накидываю идеи, куда я сейчас пойду и что проверю.
А потом иду и все поднимаю за пару минут. Главное всё делать с холодной головой. Чем больше суеты, тем больше потратишь времени на восстановление.
Пользуйтесь, отличный способ распознать оборотней, которые пиздят в резюме. Ну либо можете проводить учения если ваши девопсы заскучали, пусть разомнутся, им этого иногда не хватает.
Букв много получилось, но всё по делу. Давай, увидимся завтра.
tags: #рабочиебудни
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Сбилдил дед репку
С утра рефакторил свой говно-скрипт, который ждал создания определенного файла + проверял, что файл не пустой. И затем выполнял нужные действия. Обычно для такого херачат циклы через
Но всегда хочется большего и правильного. А в bash как раз есть третий способ реализовать подобный цикл. Называется Until.
Пример, который будет бесконечно ждать создания НЕ пустого файла, выполнять полезную нагрузку и затем прекращать свою работу.
Ключ -s как раз проверяет, существует ли файл и не пустой ли он.
У metallica есть такая песенка «until it sleeps»
А чтобы скрипт крутился НЕ бесконечно, а с определенным таймаутом, делаем так:
Спустя 10 секунд скрипт завершит свою работу даже если файл
✔️ Таймауты полезны, если запускаешь скрипт по крону. Чтобы форки не плодились.
timeout=10 - задаем таймаут в секундах
SECONDS=0 - инициализируем встроенный счетчик
Минусы конечно же есть, например время таймаута 10 секунд, файл был создан через 3 секунды, НО записывается 60 секунд. В этом случае скрипт выполнится все равно успешно. Этот момент стоит сразу учитывать и закладывать изначально адекватные значения.
Ну либо навешать пиздюлей через
Конец!
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
С утра рефакторил свой говно-скрипт, который ждал создания определенного файла + проверял, что файл не пустой. И затем выполнял нужные действия. Обычно для такого херачат циклы через
for
и while
, справедливо. Но всегда хочется большего и правильного. А в bash как раз есть третий способ реализовать подобный цикл. Называется Until.
Пример, который будет бесконечно ждать создания НЕ пустого файла, выполнять полезную нагрузку и затем прекращать свою работу.
#!/bin/bash
file=/tmp/bashdays
until [ -s "$file" ]
do
sleep 1
done
echo "вот и всё"
Ключ -s как раз проверяет, существует ли файл и не пустой ли он.
У metallica есть такая песенка «until it sleeps»
А чтобы скрипт крутился НЕ бесконечно, а с определенным таймаутом, делаем так:
#!/bin/bash
file=/tmp/bashdays
timeout=10
SECONDS=0
until [ -s "$file" ] || (( SECONDS >= timeout ))
do
SECONDS=$((SECONDS+1))
sleep 1
done
[ -s "$file" ] || exit 1
echo "вот и всё"
Спустя 10 секунд скрипт завершит свою работу даже если файл
/tmp/bashdays
отcутствует либо пустой. Ну а если все ок, то выполнится полезная нагрузка «вот и всё».timeout=10 - задаем таймаут в секундах
SECONDS=0 - инициализируем встроенный счетчик
Встроенная переменная SECONDS в Bash является специальной переменной, которая автоматически инкрементируется на количество секунд, прошедших с начала выполнения текущего скрипта или текущей подобной конструкции. Как только скрипт начинает выполнение, `SECONDS` начинает отсчитывать время с 0 и увеличивается на 1 каждую секунду. Это позволяет удобно отслеживать время выполнения скрипта или определенной части кода.
Минусы конечно же есть, например время таймаута 10 секунд, файл был создан через 3 секунды, НО записывается 60 секунд. В этом случае скрипт выполнится все равно успешно. Этот момент стоит сразу учитывать и закладывать изначально адекватные значения.
Ну либо навешать пиздюлей через
inotify
или incron
, чтобы определять точное время, когда был закрыт файл. И тогда проблем можно избежать. Но это лишнее звено.Конец!
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
У самурая нет тестов, только прод
Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.
Банально проверяем наличие файла
И да файл
А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:
Тут суть такая, во всех хост-системах
Запускаем на хостовой машине:
Запускаем в контейнере:
✔️ Может зафакапить, так как не установлен пакет procps.
Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:
<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый
После перезапуска контейнера все твои настройки сохранятся. Но лучше этим не частить, а собирать контейнеры сразу с нужной тебе хуйнёй.
Ладно, погнали дальше спасать этот прекрасный мир.
tags: #linux #bash
@BАSHDАYS | BАSHDАYS.CОM
Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.
if [ -f /.dockerenv ]; then
echo "I'm inside docker";
else
echo "I'm living in real world!";
fi
Банально проверяем наличие файла
.dockerenv
и всё! Да, так просто. Способ самый универсальный и используется разработчиками в 99% случаев.И да файл
.dockerenv
можно удалить и тогда скрипт сломается. Удобно, если хочешь помешать скриптам определять где они выполняются. НО после перезапуска контейнера файл .dockerenv
снова появится.А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:
if [ -n "$(grep 'kthreadd' /proc/2/status 2>/dev/null)" ]; then
echo "I'm living in real world!"
else
echo "I'm inside container";
fi
Тут суть такая, во всех хост-системах
PID(2) == kthreadd
. Запускаем на хостовой машине:
ps -p 2
PID TTY TIME CMD
2 ? 00:00:00 kthreadd
Запускаем в контейнере:
ps -p 2
PID TTY TIME CMD
хуй с маслом
Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:
docker commit <ID> <name>
<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый
После перезапуска контейнера все твои настройки сохранятся. Но лучше этим не частить, а собирать контейнеры сразу с нужной тебе хуйнёй.
Ладно, погнали дальше спасать этот прекрасный мир.
tags: #linux #bash
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Без скрипта не выловишь и рыбку из пруда
你好! Познакомился вчера на созвоне с китайцем, зовут его что-то вроде АнХуй. Смешной персонаж. Что-то мне 40 минут втирал на сломанном английском. Я ни слова не понял, но уверено махал головой как обезьяна на бананы.🅰️
По итогу встречи я выучил слова «Нихао» и «Херанука», а он всяко выучил — «ты, заебал» и «пиздец». Вот так и работаем. Айти объединяет.
Ну чо, поехали двигать пингвинов
Сегодня изучаем —
Эта такая штука… короче с помощью нее можно запускать команды и скрипты в новых сеансах и группах процессов. Скрипт запущенный через
Это гарантирует, что если родительский процесс получит сигнал SIGHUP, то запущенный скрипт через
Пишем башник
✔️ Скрипт будет нихуя не делать 200 секунд.
Запускаем:
Сразу видим, что оболочка продолжила работать в интерактивном режиме. Можно вводить команды и продолжать работу. А что со скриптом
Это скрипт запущен через
Видишь, он не является частью процессов bash, а работает самостоятельно, в общем дереве процессов. Запущенный скрипт не привязан к текущему терминалу.
А это скрипт
Видим цепочку, скрипт работает в текущей оболочке bash. Если закрыть оболочку, то и скрипт прекратит свою работу.
Давай сравним setsid и nohup
Если запустить так:
Наблюдаем такую картину:
Пишем
Процесс отделился от закрытой оболочки и попал в корень всех процессов. В данный момент он продолжает работу.
Теперь запускаем
А тут сразу процесс отделился от оболочки и стал корневым. Даже если написать
Хм. Не велика разница. Но она все же есть. Команда
Изучай.
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
你好! Познакомился вчера на созвоне с китайцем, зовут его что-то вроде АнХуй. Смешной персонаж. Что-то мне 40 минут втирал на сломанном английском. Я ни слова не понял, но уверено махал головой как обезьяна на бананы.
По итогу встречи я выучил слова «Нихао» и «Херанука», а он всяко выучил — «ты, заебал» и «пиздец». Вот так и работаем. Айти объединяет.
Ну чо, поехали двигать пингвинов
Сегодня изучаем —
setsid
Эта такая штука… короче с помощью нее можно запускать команды и скрипты в новых сеансах и группах процессов. Скрипт запущенный через
setsid
будет независим от родительского процесса.Это гарантирует, что если родительский процесс получит сигнал SIGHUP, то запущенный скрипт через
setsid
продолжит работу. Nohup? Почти.. Поехали в практику.Пишем башник
bashdays.sh
#!/bin/bash
echo "Starting..."
sleep 200
echo "Finished..."
Запускаем:
setsid ./bashdays.sh
Сразу видим, что оболочка продолжила работать в интерактивном режиме. Можно вводить команды и продолжать работу. А что со скриптом
bashdays.sh
? Давай запустим pstree и визуально глянем.Это скрипт запущен через
setsid
├─sshd─bash
├─sshd─bash─pstree
└─sshd─sshd
├─bashdays.sh─sleep
Видишь, он не является частью процессов bash, а работает самостоятельно, в общем дереве процессов. Запущенный скрипт не привязан к текущему терминалу.
А это скрипт
bashdays.sh
запущен напрямую, без setsid
├─sshd─bash
├─sshd─bash─bashdays.sh─sleep
Видим цепочку, скрипт работает в текущей оболочке bash. Если закрыть оболочку, то и скрипт прекратит свою работу.
Давай сравним setsid и nohup
Если запустить так:
nohup ./bashdays.sh &
Наблюдаем такую картину:
├─sshd─┬─sshd─bash─pstree
├─sshd─bash─bashdays.sh─sleep
Пишем
exit
и видим уже такое:├─sshd─sshd─bash─pstree
├─bashdays.sh─sleep
Процесс отделился от закрытой оболочки и попал в корень всех процессов. В данный момент он продолжает работу.
Теперь запускаем
setsid ./bashdays.sh
├─sshd─┬─sshd───bash───pstree
└─sshd───bash
├─bashdays.sh─sleep
А тут сразу процесс отделился от оболочки и стал корневым. Даже если написать
exit
и закрыть терминал, sleep
продолжит работу.Хм. Не велика разница. Но она все же есть. Команда
setsid
более прямой способ создания нового сеанса, тогда как nohup
просто игнорирует сигнал SIGHUP.Изучай.
tags: #bash #linux
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Как величать сервера
Мне часто задают этот вопрос, всем одно и тоже отвечать заёбисто. Поэтому вот вам пост, буду ссылку потом на него всем скидывать.
Короче нет бест-практик. Нет серебряной пули. Есть не стандартизированная самодеятельность. Если по-простому, то как хочешь, так и называй, лишь бы тебе было удобно.
Помню когда начинал играть на гитаре, не знал что аккорды имеют название. Поэтому сам придумывал эти названия (mt-1/sl-4/sep-7). Производные от Metallica, Slayer, Sepultura и т.п.
Но спустя год оказалось, что все стандартизировано и пришлось мучительно переучиваться. Да, в те времена мы еще на ZX спектрумах кодили, про интернет и не знали. А спросить за музыку было не у кого. Все методом тыка, всё на слух. Эх, это было прекрасное время.
Короче все зависит от твоего облачного провайдера, твоей инфры и вообще всё индивидуально. У меня инфра в основном вся в Selectel. Там есть разграничение по проектам. В каждом проекте можешь заводить любое количество инстансов. Ну я думаю везде что-то похожее, в яндексе по крайней мере также. В aws уже не помню, в DO тоже есть.
✔️ Моя схема как давать погоняла железякам.
По итогу имею примерно такое:
Проект bashdays, а дальше инстансы с префиксом. Цифровой индекс полезен, когда горизонтально скейлишь. Регионы и т.п. хуиту не добавляю, нет необходимости.
Если уж и надо глянуть регион, лезу в панельку селектела и смотрю в каком ДЦ у меня все это лежит. Но обычно это требуется когда пишешь тикет в саппорт. А так нахер надо. Учись упрощать!
Про балансировщик нагрузки писал в этом посте, как заебись его организовать и полезный пост по заголовкам и проксипасам. Мастрид.
Ну а так инфы по неймингу в интернете полно, я лишь показал как делаю сам. Потому что у каждого свои задачи и хотелки.
Хоть «ебанутый-носорог-1» назови, главное чтобы тебе комфортно было.
Знаешь же поговорку — Никого не слушай, НО прислушивайся! Хороших выходных тебе, увидимся.
Кстати расскажи в комментах как ты называешь свои сервера, очень интересно послушать. Всё, теперь точно до завтра!
tags: #bash #linux
@ВАSНDАYS | BАSHDАYS.CОM
Мне часто задают этот вопрос, всем одно и тоже отвечать заёбисто. Поэтому вот вам пост, буду ссылку потом на него всем скидывать.
Короче нет бест-практик. Нет серебряной пули. Есть не стандартизированная самодеятельность. Если по-простому, то как хочешь, так и называй, лишь бы тебе было удобно.
Помню когда начинал играть на гитаре, не знал что аккорды имеют название. Поэтому сам придумывал эти названия (mt-1/sl-4/sep-7). Производные от Metallica, Slayer, Sepultura и т.п.
Но спустя год оказалось, что все стандартизировано и пришлось мучительно переучиваться. Да, в те времена мы еще на ZX спектрумах кодили, про интернет и не знали. А спросить за музыку было не у кого. Все методом тыка, всё на слух. Эх, это было прекрасное время.
Короче все зависит от твоего облачного провайдера, твоей инфры и вообще всё индивидуально. У меня инфра в основном вся в Selectel. Там есть разграничение по проектам. В каждом проекте можешь заводить любое количество инстансов. Ну я думаю везде что-то похожее, в яндексе по крайней мере также. В aws уже не помню, в DO тоже есть.
База данных = db1
Редиска = rd1
Вебнода (nginx + php) = w1
Админки (nginx + php) = a1
Реплика БД = r1
Микросервисы = d1 (daemons)
Стораджи = st1
Балансировщик = b1
По итогу имею примерно такое:
bashdays-b1 (балансировщик)
bashdays-w1 (вебнода 1)
bashdays-w2 (вебнода 2)
bashdays-w3 (вебнода 3)
bashdays-a1 (админки 1)
bashdays-r1 (реплика БД)
bashdays-st1 (могильник файлов)
bashdays-st2 (реплика могильника)
bashdays-db1 (база данных)
bashdays-r1 (редиска)
bashdays-d1 (микросервисы, демоны)
Проект bashdays, а дальше инстансы с префиксом. Цифровой индекс полезен, когда горизонтально скейлишь. Регионы и т.п. хуиту не добавляю, нет необходимости.
Если уж и надо глянуть регион, лезу в панельку селектела и смотрю в каком ДЦ у меня все это лежит. Но обычно это требуется когда пишешь тикет в саппорт. А так нахер надо. Учись упрощать!
Про балансировщик нагрузки писал в этом посте, как заебись его организовать и полезный пост по заголовкам и проксипасам. Мастрид.
Ну а так инфы по неймингу в интернете полно, я лишь показал как делаю сам. Потому что у каждого свои задачи и хотелки.
Хоть «ебанутый-носорог-1» назови, главное чтобы тебе комфортно было.
Знаешь же поговорку — Никого не слушай, НО прислушивайся! Хороших выходных тебе, увидимся.
Кстати расскажи в комментах как ты называешь свои сервера, очень интересно послушать. Всё, теперь точно до завтра!
tags: #bash #linux
@ВАSНDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Вводные: У клиента есть сервак с авторизацией по ssh ключам. С виду все настроено верно. Катают ансиблом.
Проблема: При подключении к серверу, продолжает запрашиваться пароль. Хотя явно указан ключ для подключения, а на сервере прописан публичный ключ клиента в
authorized_keys
.Проблема на самом деле распространенная. Для отладки открываем логи авторизаций и смотрим что происходит. И да, никто блядь не читает логи, а сразу начинают искать суслика, которого нет. ЧИТАЙ ЛОГИ!
Понятно дело, в логах видим ошибку:
message repeated 4 times: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
С этой ошибкой ты всяко бодался. Смотрим права. И действительно, на файле
authorized_keys
стоят 3 топора (777). А должно быть 600. Как фиксить, ежу понятно.Как сказать пингвину, чтобы он забил хуй на проверку прав для этих ключей?
А вот так, добавляем в
/etc/ssh/sshd_config
строчку:StrictModes no
Ну и рестартим демона
systemctl restart sshd
Всё. Теперь можешь играться с правами ключей. Хоть 000 выстави. Права проверяться не будут и тебя успешно пропустят без пароля.
Когда StrictModes установлено в no, SSH сервер не будет так строго проверять права доступа к этим файлам и каталогам. Это означает, что, например, если домашний каталог пользователя имеет права доступа, которые обычно не допускаются (например, другие пользователи могут читать каталог), SSH сервер все равно будет работать.
Установка StrictModes no уменьшает уровень безопасности, так как позволяет некоторым нежелательным правам доступа с точки зрения безопасности, но это может быть полезно в некоторых сценариях, например, при развертывании на тестовых серверах или в средах, где безопасность не является приоритетом.
Короче для дебага фишка мастхев, если в логах хуй с маслом, включаем эту опцию и проверяем, действительно ли дело в правах на ключи или дело в кривых руках.
Финк диферент!
tags: #linux #debug
@ВАSНDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Event loop из семи залуп.
✔️ Сегодня запускаем bash скрипт из nginx по локейшену.
Идея такая, при открытии урла в браузере
А зачем это нужно? Элементарно — чтобы запустить Bash скрипт!
Но никогда так не делай.
Чтобы подобное реализовать, тебе понадобится
Я возьму
Ставим врапер:
Закидываем скрипт в
В конфиге nginx городим локейшен:
Заранее убедись что сокет
Открываем
Но это еще не все. В папке
Для
Я этот код не проверял, он всяко не работает, на коленке накидал, но думаю главное тут суть.
Кстати через php наверное тоже можно башник дернуть, там сокет так же подкинуть и через «хуй-пизда-лопата» запустить скрипт.
Вообще промышлять таким - фу! Если ты кому-то расскажешь, то тебя выгонят ссаными тряпками. Всё чисто ради экспериментов. Изучай!
tags: #linux #nginx #bash
@ВАSНDАYS | BАSHDАYS.CОM
Идея такая, при открытии урла в браузере
https://bashdays.com/bashdays.sh
запускается bash скрипт, который лежит на сервере в папке /tmp/bashdays.sh
.А зачем это нужно? Элементарно — чтобы запустить Bash скрипт!
Но никогда так не делай.
Чтобы подобное реализовать, тебе понадобится
fcgiwrap
либо lua
. Из обычного nginx, который в коробке, это сделать невозможно. Политика безопасности, вся хуйня.Я возьму
fcgiwrap
, не хочу компилить модуль lua
. Если у тебя есть lua
, можешь через него подобное реализовать. Примеры ниже.Ставим врапер:
apt install fcgiwrap
Закидываем скрипт в
/tmp/bashdays.sh
#!/bin/bash
echo "Content-type: text/html"
echo ""
echo "<h1>Hello Bashdays</h1>"
echo "<p>This is a test bash script.</p>"
echo "hello bashdays" > file.txt
В конфиге nginx городим локейшен:
location /bashdays.sh {
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME /tmp/bashdays.sh;
include fastcgi_params;
}
Заранее убедись что сокет
fcgiwrap
создался и лежит в нужном месте. На этом собственно всё. Да, надо сделать еще nginx reload
.Открываем
https://bashdays.com/bashdays.sh
и лицезрим «Hello Bashdays This is a test bash script.».Но это еще не все. В папке
/tmp
появился файл file.txt
. Как видишь все получилось. Дальше включай фантазию и твори.Для
lua
это будет выглядеть как-то так:
location /bashdays.sh {
content_by_lua_block {
os.execute("/tmp/bashdays.sh")
}
}
Я этот код не проверял, он всяко не работает, на коленке накидал, но думаю главное тут суть.
Кстати через php наверное тоже можно башник дернуть, там сокет так же подкинуть и через «хуй-пизда-лопата» запустить скрипт.
Вообще промышлять таким - фу! Если ты кому-то расскажешь, то тебя выгонят ссаными тряпками. Всё чисто ради экспериментов. Изучай!
tags: #linux #nginx #bash
@ВАSНDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM