Про эстетику и терминал

Записывал я тут какое-то видео и заметил, что меня пиздец бесит такое поведение:

1. Открываю терминал
2. Запускаю к примеру sleep 10
3. Курсор перескакивает на новую строку

Но команда sleep еще не завершилась, а курсор уже выпрыгнул из штанов.
ㅤ
Хочу, чтобы курсор после запуска команды не перескакивал на новую строку, а ждал завершения команды.

Люблю я себе головняк создать на ровном месте. Поехали решать чо!

cursor_killer() {

echo -ne '\e[?25h'
trap 'echo -ne "\e[?25l"; trap DEBUG' DEBUG
}

PROMPT_COMMAND='cursor_killer'

Получилась такая упоротая и непонятная функция.

Что происходит?

Инициализируем переменную PROMPT_COMMAND. Это команда выполняется перед выводом строки приглашения (prompt).

Дальше делаем курсор видимым с помощью echo. А следом скрываем курсор перед выполнением каждой команды с помощью trap.

В trap мы установили обработчик для псевдо-сигнала DEBUG.

➡️ help trap

If a SIGNAL_SPEC is DEBUG, ARG is executed before every simple command.

\e[?25h = включает отображение курсора (h = "show")

\e[?25l = отключает отображение курсора (l = "low visibility" или "hide")

Получилось так:

1. Первая команда делает курсор видимым.
2. Вторая команда установит обработчик на сигнал DEBUG.
3. Обработчик скрывает курсор и сбрасывается обработчик для сигнала DEBUG в дефолт.

Сохраняем эту поделку в cur_killer.sh и запускаем когда нам это нужно. Либо делаем source cur_killer.sh.

Ну а чтобы эта штука оказалась тебе полезной, можешь написать свой отладчик bash скриптов.

К примеру будем выводить команду, перед её выполнением:

trap 'echo "RUN: $BASH_COMMAND"' DEBUG

Теперь позапускай sleep, ls или что-то еще, перед выполнением команды, на экран будет выводиться команда. К примеру так:

trap 'echo "RUN: $BASH_COMMAND"' DEBUG

ls

RUN: ls --color=auto -la

Вот такой фигнёй я порой занимаюсь, а не сериальчики смотрю.

Покеда! Вечером еще увидимся, декабрь прям шепчет на контент и интеграции. В январе уж отдохнем.

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

Пули закончатся раньше чем ноги

Откапал сегодня в одном коммерческом интерпрайзе такую конструкцию:

while [ $(pgrep process_name)>'0' ]  
do  
 sleep 5  
done

Смотрю я в неё и понять не могу, а нахуя?
ㅤ
Давай разберемся что тут не так.

«[» = это аналог или синоним встроенной команды «test». Если не задавать оператор, то на пустой строке вернется FALSE. Ну и логично что вернется TRUE если срока не пустая.

«while» — ежу понятно, условный цикл. Будем вертеть на хуй, пока команда заданная в условие возвращаешь истину. В нашем случае эта команда «test».

«pgrep» — ищем процесс с именем process_name. Эта штука выводит на стандартный вывод PID процесса. Если процесс не найден, код возврата отличный от нуля и нуль в противном случае.

«$(command)» — Command запускается в подоболочке. Результат выполнения, подставляется в текущую позицию.

«>» — Перенаправляет результат работы команды в файл (в нашем случае файл 0). Существующий файл, перезаписывается. Несуществующий, будет создан.

Понял в чем дело? Нет? Давай дальше…

Вопрос — нахуя здесь «test»? Цикл и так является условным и сам проверяет что вернула команда. Получается избыточность.

Команда test — Предназначена для проверки типа файла и сравнения чисел и строк. Возвращает код возврата 0 (истина) или 1 (ложь) в зависимости от вычисления выражения. Выражения могут быть как унарными, так и бинарными.

Такое обычно херачат, либо по привычке, либо когда нужно быстрое решение, а времени на ресерч нет. Работает да и хрен с ним.

Вся эта конструкция могла бы выглядеть так:

while pgrep process_name &> /dev/null  
do  
 sleep 5  
done

Цикл будет шуршать, пока команда pgrep отрабатывает без ошибок и находит процесс.

Вот такая вот романтика, на хую два бантика… Изучай!

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

Набрёл сегодня на мануал по установке ack, а там такое:

curl https://beyondgrep.com/ack-2.28-single-file > ~/bin/ack && chmod 0755 !#:3

ack — инструмент для поиска текста в файлах, который часто используется разработчиками как более удобная и современная альтернатива `grep`. Он написан на Perl и ориентирован на работу с кодом.

В строке, в конце есть непонятности: !#:3
ㅤ
Опять какая-то магия, а магию мы с тобой любим.

Давай разберемся.

В данном случае !#:3 — это конструкция, связанная с историей команд в оболочке Bash/Zsh.

! = Используется для доступа к истории команд.

Например, !! повторит последнюю команду, а !123 выполнит команду с номером 123 в истории.

# = Ссылается на текущую команду, которая в данный момент пишется.

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

:3 = Указывает, что нужно взять третий аргумент в текущей строке.

Соответственно:

:1 — первый аргумент
:2 — второй аргумент
:3 — третий аргумент

Как это работает?

Сначала выполняется команда curl, которая скачает файл ack-2.28-single-file и сохранит его в ~/bin/ack.

После этого, команда chmod изменяет права доступа для файла.

А !#:3 подставляет третий аргумент текущей команды, то есть ~/bin/ack.

И по итогу команда превращается в chmod 0755 ~/bin/ack

 curl http://beyondgrep.com/ack-2.28-single-file > ~/bin/ack && chmod 0755 ~/bin/ack

Вот и вся магия. Упорото? Аще!

А зачем это нужно?

- удобно для автоматизации и избежания дублирования ввода
- снижает вероятность ошибок, если накосячил в путях

Короче эта хреновина делает команду более динамичной и минимизирует рукоблудие.

Штука прикольная, как говорится — век живи, век учись.

🔥 Ну и с пятницей друзья! Еще пару недель и каникулы.

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

🎄 Моя! 🎄

Ну чо, кто на ёлку богат уже? Кидайте в комменты ёлки и своё пятничное настроение, пиво там, вискарь или чо там у вас.

Так вот

🔤🔤🔥🔤🔤🔤🔤

Эта музыка будет вечной, если я заменю батарейки

#!/bin/bash
declare -i a=9223372036854775803
for i in {1..10};do
  echo $((a++))
done

Нука бармалеи, чо будет?

+ прикол

#!/bin/bash
declare -i a=1
for i in {1..64};do
  a=a*2
[[ $i -gt 60 ]] && echo $i,$a
done

Изба архитектурных костылей

Вспомнил тут приколюху при создании нового пользователя в Linux. Ща расскажу.

Короче при создании нового юзера, создается папка /home/user и в ней минимальный набор файлов, типа .bashrc, .profile. И все, больше в ней ничего нет.

Про различия .profile/.bashrc и т.п. я писал в этом посте.

Но я хочу для новых пользователей сразу создавать необходимую структуру папок.
ㅤ
Например:

/home/user/www/htdocs
/home/user/www/logs
/home/user/www/tmp

Ну тут логично, триггерим какой-нибудь bash скрипт который через mkdir создаст эти папки.

НО так не интересно! 😲

В коробке линукса для этого есть /etc/skel. Эта папка служит шаблоном для домашнего каталога нового пользователя.

Вот это нихуясе? Ага!

Работает это так:

sudo mkdir -p /etc/skel/www/htdocs /etc/skel/www/logs /etc/skel/www/tmp

Создаём необходимый шаблон со структурой папок.

Так-же можешь добавить шаблонные файлы .bashrc и .profile

Теперь создаем нового пользователя:

sudo useradd -m bashdays

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

Ну красота же!

Можешь создавать альтернативные шаблоны структур и затем это раскатывать так:

sudo useradd -m -k /custom/skel bashdays

И да, все права на папки и файлы автоматически установятся на те что нужно.

Ну и на закуску:

Не обязательно хостить пользователей в папке /home, можно сделать так:

sudo useradd -m -d /var/www/bashdays bashdays

В этом случае домашняя папка юзера будет расположена в /var/www/, а в /etc/passwd будет такое:

bashdays:x:1000:1000::/var/www/bashdays:/bin/sh

Вот так вот и живем. Изучай.

А какие приколюхи знаешь ты? Камон в комменты.

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

Привет. Я устал от сложностей написания Bash курса и решил отдохнуть и написать статью.

🔤🔤🔥🔤🔤🔤🔤

Если кто-то не пьет на Новый Год - читайте эту статью. Голова кружится не хуже, чем от алкоголя.

ㅤ
Сегодня поговорим об очень редко используемом и на мой взгляд, абсолютно ненужном и неадекватно работающем операторе bash. И сравним его с классикой.

Представляю Вашему вниманию тернарный (троичной) оператор.

В мануале он выглядит так:

expr1 ? expr2 : expr3

Работает оператор так: если expr1 истина, то результат expr2, иначе expr3.

Для исследования я написал небольшую тестовую программу

#!/bin/bash
declare -i c=033 #27
declare -i d=044 #36
declare -i k=0 #counter

function wait2sec(){
  sleep 2
  echo $1
}

SECONDS=0
a=$((1 == 2?$(wait2sec c):$(wait2sec d))) #0
echo $((k++)) sec=$SECONDS a=$a

SECONDS=0
((a=1==2?$(wait2sec c):$(wait2sec d))) #1
echo $((k++)) sec=$SECONDS a=$a

SECONDS=0
a=$((1==2?$(wait2sec c):$(wait2sec d))) #2
echo $((k++)) sec=$SECONDS a=$a

SECONDS=0
[[ 1 == 2 ]] && a=$(wait2sec c) || a=$(wait2sec d) #3
echo $((k++)) sec=$SECONDS a=$a

SECONDS=0
[[ 1==2 ]] && a=$(wait2sec c) || a=$(wait2sec d) #4
echo $((k++)) sec=$SECONDS a=$a

####### result #############
# 0 sec=4 a=36
# 1 sec=4 a=36
# 2 sec=4 a=36
# 3 sec=2 a=d
# 4 sec=2 a=c

Функция wait2sec ждет 2 секунды и печатает первый параметр. Дальше идут пять как бы одинаковых блоков.

1 == 2 - expr1 (false) 
wait2sec c - expr2
wait2sec d - expr3

Анализируем результаты:

1. переменные d и с описаны как целые, но начинаются с 0, поэтому bash интерпретирует их как восьмеричные.

2. Тернарный оператор может использоваться только внутри арифметической подсистемы ((...)), в которой переменные допускается извлекать(получать значение) без знака $, поэтому c и d интерпретируются как переменные.

3. У тернарного оператора допустима даже "упоротая" форма (блок 1)

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

5. В блоке 4 допущена ошибка (нет пробелов вокруг знака сравнения, поэтому 1==2 - интерпретируется не как результат сравнения, а как не пустая строка, поэтому результат (истина) не верный. Такие ошибки очень трудно отлаживать.

6. В отличие от классического, башевского, сравнения при использовании тернарного оператора expr2 и expr3 вычисляются вне зависимости от условия. Об этом говорит удвоенное время выполнения блока.

🔤🔤🔤🔤🔤🔤
🅰️🅰️

Всех приглашаю на БЕСПЛАТНЫЙ курс BASH. 👇

➡️ Записаться: https://xn--r1a.website/+0j3ugyfKJH1iYzg6

Начало курса 11 января. До окончания записи 25 дней.

Ссылку на группу для общения по курсу сообщу после начала курса. Заходите и проходите опросы.

tags: #bash #linux
—
🔔 @bashdays➡️ @gitgate

Отлаживал сегодня багу связанную с правами доступа. В суть произошедшего вникать не будем.

Главное, что багу помогла решить утилита — namei. Устанавливать не нужно, идет в коробке.

Утилита namei — разбивает путь до папки/файла на составляющие и выводит права доступа для каждой из них.

Из этого нихуя не понятно, давай просмотрим на практике.
ㅤ
У меня php работает под юзером bashdays. Но при открытии админки, нихуя не работает.

Проверяю путь до админки:

namei -l /var/www/bashdays/htdocs/wp-admin/index.php

f: /var/www/bashdays/htdocs/wp-admin/index.php
drwxr-xr-x root     root     /
drwxr-xr-x root     root     var
drwxr-xr-x bashdays bashdays www
drwxr-xr-x bashdays bashdays bashdays
drwx--x--x bashdays bashdays htdocs
drwx------ root root wp-admin
-rw-r--r-- bashdays bashdays index.php

Хм… и вижу, что с правами каталога wp-admin что-то совсем не так.

Но почему не использовать ls -la?

ls -la  /var/www/bashdays/htdocs/wp-admin/index.php

-rw-r--r-- bashdays bashdays /var/www/bashdays/htdocs/wp-admin/index.php

Вот и ответ.

Ключи для namei:

l — показывает подробный вывод (long listing) для каждого компонента пути.
m — показывает права доступа (в виде числового значения, как ls -l).
o — показывает владельца и группу каждого компонента.
v — детализирует информацию о путях и ошибках.
x — показывает права доступа в виде rwx (читаемо).

Давай сравним

⚪ namei

- разбирает полный путь на компоненты
- показывает каждый компонент пути и его права
- отображает права доступа на каждый узел пути
- раскрывает симлинки и показывает, куда они ведут
- выводит ошибки если путь где-то прерывается

⚪ ls

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

Я namei пользуюсь достаточно редко, но метко. В основном руки заточены на ввод именно ls -la. Тут уж как привык. Возможно namei тебе зайдет.

Изучай.

tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgate

В bash есть переменная IFS, отвечающая за разделитель полей при чтении stdin, но нет переменной OFS - для выходного разделителя полей.

🔤🔤🔥🔤🔤🔤🔤

Или есть? Для преобразования можно использовать переменную $* в кавычках.
ㅤ
Генерим CSV (comma separated value)

#!/bin/bash

IFS=",$IFS" # добавили запятую
set 1 2 3 4 "5 6" 7 # установили параметры
echo ' $* ='$*
echo '"$*"='"$*"

###################
# $* =1 2 3 4 5 6 7
#"$*"=1,2,3,4,5 6,7

Обычно IFS содержит символы пробел, табуляция, перевод строки.

Если использовать "$*" (в кавычках обязательно), то в качестве разделителя используется первый символ IFS.

Будьте внимательны, команда set устанавливает параметры командной строки текущего экземпляра bash ($1...$N изменятся).

tags: #bash #linux
—
🔔 @bashdays➡️ @gitgate

Собирал docker контейнер и чет меня лог сборки прям напряг.

То есть то, что отмечено на скрине красным прямоугольником, это область которая прокручивается. И предыдущий текст теряется.
ㅤ
Ну хуйня же! — подумал я и пошел копать.

А всё, как обычно, просто, в строке сборке делаем так:

docker build -t "setuppython" --progress=plain .

Устанавливаем параметр progress=plain и радуемся. Лог сборки прекращает ротироваться и весь мусор теперь на экране.

Как альтернатива, можно сделать так:

export BUILDKIT_PROGRESS=plain

И теперь не нужно подставлять в каждую команду сборки этот параметр.

progress может быть = auto, plain, и tty

tty вывод будет «более красивым» для интерактивных терминалов (то есть он будет перезаписываться).

plain будет просто выводить все. 

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

Такие дела. Изучай.

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

Здрасти. Сегодня опять про шаблоны и создание нового пользователя. В прошлом посте я показал skel. Но есть еще одна хуйня, где можно тонко это поднастроить.
ㅤ
Находится оно здесь: /etc/default/useradd

И выглядит это так:

GROUP=100
HOME=/home
INACTIVE=30
EXPIRE=2024-12-31
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
UMASK=077
USERGROUPS_ENAB=yes
PASS_MAX_DAYS=90
PASS_MIN_DAYS=1
PASS_WARN_AGE=7

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

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

GROUP = указывает GID (ID группы) по умолчанию для новой учетной записи.

И чо у всех юзеров будет GID = 100? Неа!

Этот параметр будет работать, только в случае если в файле /etc/login.defs выставлено USERGROUPS_ENAB=no. Во всех остальных случаях он будет проигнорирован.

Заметь что в /etc/default/useradd можешь реврайтить USERGROUPS_ENAB и не лезть в /etc/login.defs.

По умолчанию USERGROUPS_ENAB=yes. В этом случае для каждого пользователя создаётся его собственная группа с тем же именем, что и имя пользователя. И у этой группы будет уникальный GID.

Например, для пользователя bashdays создаётся группа bashdays с GID 1000. Для следующего будет 1001 и так далее.

Короче значение GROUP=100 применяется только тогда, когда пользовательская группа не создаётся автоматически.

Такие дела, бери на вооружение.

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

Что в рот влезло, то и полезно

тыгыдык вайл инфинити

while true; do echo -e "\a"; sleep 0.5; done

tags: #tricks #bash
—
🔔 @bashdays➡️ @gitgate

В linux существует куча всяких оболочек, я имею в виду не bash/zsh, а конкретно их типы: login, non-login, interactive, restricted и т.п.

Очередной зоопарк с которым особо никто не разбирается. Давай закроем эту дырку. ㅤ

Interactive Shell — ну тут ежу понятно, ты вводишь в терминале буковки, а оно тебе в ответ что-то выдаёт. Интерактивно? Конечно! По умолчанию именно этот тип стартует при запуске терминала.

На этом можно и закончить, но хуй там плавал, поехали дальше.

Non-Interactive — Логично? Логично! Этот тип используется в основном для выполнения скриптов или задач в кроне.

Когда ты запускаешь скрипт: ./bashdays.sh, интерактивная оболочка смотрит в скрипт и такая — ага, вижу shebang (#!/bin/sh) Запускаю интерпретатор sh.

Это и будет считаться не интерактивной оболочкой, все запустится где-то там внутри, в кишках.

Что интересно, при запуске в такой оболочке все твои настройки в .profile/.bashrc игнорируются.

Почему? Из-за совместимости, вдруг ты в .bashrc нахуячил своих переменных и команд, а потом решил этот скрипт перенести на другую машину где нет этих переменных и команд. Такие дела.

И в большинстве случаев здесь кроется проблема с выполнением скрипта из крона. Ручками запускаешь — работает. А из крона — нет! Потому что проигнорированы твои поделки в .bashrc и profile.

Как вариант, пиши #!/bin/bash или в кроне явно указывай как запускать твой скрипт: bash script.sh

Login = Запускается при входе в систему (например через ssh). Оболочка входа перечитывает файлы: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile.

Чтобы определить текущий тип оболочки, запусти команду:

echo $0

Если вывод начинается со знака «-» это и есть login shell.

Ну или так:

[[ $- == *i* ]] && echo "Interactive" || echo "Non-Interactive"

Non-Login = запускается из существующей сессии (например, внутри терминала из GUI). То есть не требуется авторизация. Не читает ~/.bash_profile вместо этого использует ~/.bashrc.

Нипонятно… давай на примере:

1. Ты приходишь домой с работы.
2. Зашел через парадную дверь Login Shell.
3. Снимаешь трусы, всё происходит по определённым правилам (файл .bash_profile).

Что происходит:

- Ты готов к долгому пребыванию дома.
- Тебя «встречают» файлы конфигурации входа (.bash_profile).

4. Ты внутри дома, и открываешь окно, чтобы покурить.
5. Non-Login Shell = это как открыть окно внутри дома.
6. Ты не снимаешь трусы заново — ты уже дома!

Файлы .bash_profile не используются, потому что ты уже «внутри». Вместо этого, ты используешь «внутренние» правила дома (это как .bashrc).

Login Shell: Зашёл в дом через дверь — загружается .bash_profile.

Non-Login Shell: Открыл окно, уже находясь в доме — загружается .bashrc.

Restricted Shell = ограниченная оболочка, кастрированные команды, закрученные гайки. Обычно делают для безопасности, чтобы криворукий юзер ничо не сломал.

Возможно ты слышал про rbash, это оно и есть.

System Shell = системная оболочка, используется системой для выполнения фоновых задач и скриптов инициализации (init, systemd). Зачастую это /bin/sh.

Subshell = Подоболочка, создается при выполнении скрипта или команд в скобках () или с помощью bash -c. Подоболочка наследует переменные родительской оболочки, но не влияет на них после завершения.

Например: (cd /tmp && ls)

Есть еще Interactive Login, Interactive Non-Login.

1. Интерактивная оболочка, которая требует входа пользователя (например, через SSH).

2. Интерактивная оболочка, открытая из GUI терминала, но не требует аутентификации пользователя.

➡️ Почитать про shebang
➡️ Почитать про файлы .profile/bashrc и т.п.

—

Да и вроде всё, закончился зоопарк, по крайней мере про другие типа оболочек я не слышал, либо забыл нахуй.

Напиши в комменты если что-то можно сюда еще приплести, будет интересно.

Увидимся! Шестидневная рабочая неделька обещает быть томной.

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

Привет чокаво.

Ребенок щас вопрос задал — пап, а в чем разница? Этож одно и тоже?

source script.sh 
. script.sh
./script.sh

В первых двух случаях, да это одно и тоже. Source и точка (как макдак блядь), это идентичные команды. Точка сделана для краткости.
ㅤ
Команда source и точка, используется для выполнения команд из файла в текущем сеансе оболочки.

VAR="bashdays"

source script.sh 
. script.sh

Передаем в скрипт переменную VAR, по итогу если в скрипте сделать echo $VAR, то на экран выведется слово — bashdays.

Если же сделать так:

VAR="bashdays"

./script.sh 

Нихуя не выведется и даже не запустится если нет атрибута +x.

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

Чтобы это заработало нужно сделать:

export VAR="bashdays"
./script.sh 

Ну и захуячить chmod +x script.sh, тогда все взлетит.

Ааааа, еще в скрипте тебе нужно обязательно вставить shebang.

В случае с source и точка, эти пиздострадания не нужны. Не нужно ничего экспортировать, выставлять +x и добавлять shebang.

➡️ source script.sh и . script.sh

Новый процесс: Нет
Изменяет окружение текущей оболочки: Да
Требует shebang: Нет
Требует права на выполнение: Нет

➡️ ./script.sh

Новый процесс: Да
Изменяет окружение текущей оболочки: Нет
Требует shebang: Да
Требует права на выполнение: Да

Когда это и где применять?

- Используем source и точку для скриптов, которые должны изменить текущее окружение.

- Используем ./script.sh для независимого выполнения скрипта.

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

tags: #linux #bash
—
🔔 @bashdays➡️ @gitgate

В LF ребята частенько впадают в ступор, пытаются запушить в мастер, а оно такое — эй дядя, иди на хуй, такой ветки нет!

Мануалы связанные с этим есть, а ветки нет?
ㅤ
В смысле блядь нет? Всю жизнь была, а теперь нет?

Притащу сюда, раз из 10 человек 2е обязательно поинтересуются. Буду ссылку на пост давать, оптимизация процессов.

Это давнишняя история. Ёбнутые дядьки с загнивающего запада кукухой поехали и такие — мы потомки рабов, негоже нас оскорблядь!

А в чем оскорбление?

Обида на слово «master»

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

Ты типа slave (раб), а целая ветка в гите — «хозяин».

Отправляйся на плантацию в IDE и ебашь больше кода, а затем приноси его «хозяину»!

Ну короче ты понял, господа ёбу дали, лишь бы не работать.

Ничо против не имею, у каждого свои загоны.

Теперь в лучшем случае гит ветка по умолчанию называется — «main».

А какая ветка у тебя основная? У меня «master», ебал я эти качели.

Подробнее и душераздирающе можно почитать тут (на русском), особенно комменты доставляют удовольствие.

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

Увидал сегодня у коллеги такое:

- name: Установка глобального PATH для Linux
  hosts: all
  become: true
  tasks:
    - name: Создать скрипт для глобального PATH
      copy:
        dest: /etc/profile.d/custom_path.sh
        content: |
          export PATH="/usr/bin:/bin"
        mode: '0644'
      notify: Reload profile

  handlers:
    - name: Reload profile
      command: source /etc/profile

это кусок ансибла если чо

Что это за ебать костыль и нахуя?
ㅤ
А это оказывается регламент такой внутренний, какие-то требования, которые должны быть применены при настройке новых серверов. И это только 1% из этого плейбука, показать весь по объективным причинам не могу.

Короче суть — создается чистая переменная PATH, на глобальном уровне.

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

Определяются только базовые пути.

Безопасность:

- Уменьшается риск выполнения вредоносного кода из непредсказуемых каталогов.
- Снижается вероятность атаки типа Path Hijacking, когда злоумышленник подсовывает вредоносные программы в каталоги, находящиеся в начале PATH.

Предсказуемость:

- Скрипты и процессы используют конкретные версии утилит, а не случайные исполняемые файлы из пользовательских каталогов.

Чистая среда для скриптов:

- В автоматизированных сценариях, например, в CI/CD, чистая PATH помогает избежать конфликтов из-за пользовательских переменных окружения.

Системное администрирование:

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

Например:

#!/bin/bash

export PATH=/usr/bin:/bin
if ! command -v curl &> /dev/null; then
    echo "curl не установлен или не доступен в чистом PATH"
    exit 1
fi

echo "curl доступен, продолжаем..."

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

Тема конечно больше про безопасность и в обычной жизни встречается крайне редко, всем насрать на Path Hijacking.

Пусть за это специально обученные люди отвечают. У нас лапки.

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

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

Задача стояла такая: Я работаю в офисе и порой хожу посрать, но кругом хакеры, ноут с собой постоянно таскать не могу, он прибит гвоздями, а терпеть не вариант.
ㅤ
Ну ты понял. Тип захотел, чтобы его ноут сфоткал ебальник коллеги, который возможно вынашивает коварный план. И однажды попытается взломать его пароль из 128 символов.

Сказано сделано, дополнительно прикрутил фичу с оправкой фотки в телегу.

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

#!/bin/bash

# Херачим переменные
TOKEN="BOT_TOKEN"
CHAT_ID="CHAT_ID"
USER=$(whoami)
TIMESTAMP=$(date '+%Y-%m-%d_%H-%M-%S')
IMAGE_PATH="/tmp/ebalo-${USER}-${TIMESTAMP}.png"

# Делаем фотку с вебки
if ffmpeg -y -t 1 -f video4linux2 -s 640x480 -r 30 -i /dev/video0 -f image2 "$IMAGE_PATH"; then
    echo "✅ Ебальник успешно захвачен: $IMAGE_PATH"
else
    echo "❌ Ошибка: Не удалось захватить ебальник"
    exit 1
fi

# Пулим фотку в телегу
RESPONSE=$(curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendPhoto" \
    -F chat_id="$CHAT_ID" \
    -F photo="@$IMAGE_PATH" \
    -F caption="🚨 Хакер пойман, лови ебальник: $USER на $(hostname)")

# Проверяем респонс
if echo "$RESPONSE" | grep -q '"ok":true'; then
    echo "📨 Ебальник успешно отправлен в Telegram"
else
    echo "❌ Ошибка: Не удалось отправить ебальник в Telegram"
    echo "Ответ Telegram API: $RESPONSE"
fi

# Подчищаем за собой
rm -f "$IMAGE_PATH"

Делаем скрипт исполняемым (иксим через чмод), кидаем этот скрипт например сюда: /usr/local/bin/

Добавляем строчку в /etc/pam.d/common-auth

auth optional pam_exec.so /usr/local/bin/ebalo_send.sh

optional = скрипт не блокирует аутентификацию, даже если выплюнет ошибку

Если хочешь чтобы скрипт был обязателен для выполнения, замени optional на required.

Работает так:

- При неудачной аутентификации PAM вызывает скрипт ebalo_send.sh

- Скрипт делает снимок ебальника с камеры и отправляет его в телегу

Да, не забудь проверить что у PAM есть разрешение на доступ к /dev/video0 и на выполнение скрипта.

Такие дела. Бери на вооружение, может где-то и пригодится.

Ну и свои варианты кидай в комменты, всяко чото интересное всплывет.

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

В каждом из нас живет «Топографический кретин», это такое общее понятие. Например, когда путаешь лево и право или коммит разработчика с куском гавна.

Меня это коснулось с командами chmod и chown. Ну вот блядь так получилось. Как только нужно права поменять или атрибуты поставить — хуй там плавал, начинаю троить и перепроверять себя в гугле.
ㅤ
На помощь пришли «якоря». Это что-то из психологии или НЛП, точно уже не помню, не скажу.

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

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

chown = change owner
chmod = change mode

В первом случае ключевое слово: Owner (владелец), английский я знаю, поэтому якорюсь на английское «овнер».

Овнер значит работа с правами. (часто слышал от пиэмов — кто сука овнер у этой задачи?)

Соответственно для второго, ключевое слово: Mode (режим доступа), якорюсь конкретно на «моде».

У этого файла должны быть «модные» права доступа.

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

Кстати с ключами по tar аналогично, в чатике как-то обсуждали эту тему. Илья закинул якорей типа:

czf - create ze file
xzf - eXtract ze file

Такие дела. Любой кретинизм можно забагфиксить, хоть и костылями, но работать будет.

А у тебя какой «кретинизм»? На чем троишь? Пиши в комменты, попиздим.

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