Ух ты сколько нас тут много стало. Привет, кого не видел. Давай поговорим про утилиту JC. Про нее почти никто не знает, значит самое время познакомиться.

JC это JSON конвертер на основе встроенных парсеров.

Если коротко, то с помощью jc можно конвертировать выхлоп различных утилит в json формат, а потом уже по-человечески извлекать данные.

Например, я хочу получить json от выхлопа iptables. Запускаю:

iptables -L | jc --iptables

И по итогу получаю годноту:

[{"chain":"INPUT","rules":[]},{"chain":"FORWARD","rules":[{"target":"DOCKER-USER","prot":"all","opt":null,"source":"anywhere","destination":"anywhere"},{"target":"DOCKER","prot":"all","opt":null,"source":"anywhere","destination":"anywhere"}..

Ну красота же. JC ограничена парсерами, но из коробки там прям на богатом все (около 50ти). Crontab, csv, ls, fstab, date, ping и т.п. Выбираешь парсер под нужную тебе задачу и получаешь готовый к работе массив данных.

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

JC так же можно использовать как модуль в python, так что, тут не только у башников праздник.

🐱 Страница проекта на github
🟢 Установка: apt/yum install jc

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

tags: #linux #bash #utilites
—
💩 @bashdays

Спокойно! Завтра устроим выходной по постам, на сегодня это последнее чтиво, обещаю. Внезапная интеграция вылезла, нужно перекрывать. Давай на сон грядущий поговорим про интерпретатор.

Все что работает на базе ядра linux, создание процесса происходит в два этапа. Процесс клонируется с помощью системных вызовов fork и clone. А копия процесса замещается кодом из указанного файла (exec). Детали пока опущу, речь про другое.

Ты всяко знаешь, что скрипт должен начинаться с символов #!. Эта штуковина называется SheBang.

Если дословно: SheBang = Она взрывает. Bang Bang, Feuer Frei! Как у Rammstein песенка, сразу фильм XXX на ум приходит. С лысым ЧСВ мужиком, а не про выгоревших чуваков позади дивана с одной миниатюрной мадмуазелью с дрочильного сайта.

В общем после #! нужно указать путь до интерпретатора, обычно мы с вами фигачим /bin/bash или питончик какой нибудь.

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

Если из командной строки запустить скрипт и системный вызов execve возвратит ошибку ENOEXEC

Процесс оболочки bash будет сам пытаться выполнить скрипт.

EXECVE() = выполняет программу, заданную параметром filename. Программа должна быть или двоичным исполняемым файлом, или скриптом, начинающимся со строки вида #!.

ENOEXEC = исполняемый файл в неизвестном формате, для другой архитектуры, или же встречены какие-то ошибки, препятствующие его выполнению.

В большинстве случаев ENOEXEC возвращается если первая строка не начинается с #! либо первая строка начинается с #! и в строке больше нет символов кроме пробелов и табуляций.

Так вот, это запустится:

#!
echo 'Have a nice bashdays'
exit

И это тоже запустится:

# super comment
echo 'Have a nice bashdays'
exit

Ну и это аналогично залетит в сакцесфул:

echo 'Have a nice bashdays'
exit

Так что не обязательно указывать нашу любимую конструкцию #!/bin/bash, интерпретатор тот еще жук и учитывает такие нюансы.

Если интересно поподробнее про это почитать, есть клевый мануал про всю эту суету с «ОнаВзрывает» или SheBang. Правда на английском, но с переводчиком вменяемо.

Исследуйте господа и дамы.

Всем котиков и доброй ночи 🚶‍♀️ 😎 ☠️ пойдука я дрыхнуть! А завтра наконец-то пятница и нет никаких ретроспектив и созвонов. Ура!

tags: #linux #bash
—
💩 @bashdays

Ура, я кажется выспался и почти отошел от дегустации чачи. В прошлую пятницу, коллега попросил помочь ему накидать промпт, ну знаешь же там все эти PS1/PS2/PS3. Короче приглашение командной строки типа: root@bashdays:~#.

А мне сука так лень было этим заниматься, опять документацию поднимать, вспоминать все эти ключи и параметры. Короче Фууу!

Сижу думаю, как послать в пешее эротическое и не обидеть особо. Долго думать не пришлось. Все уже придумано за нас.

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

Чёрт, как правильно промпт или промт? Промт по моему какой-то переводчик раньше такой был, в общем не суть.

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

- Bash Prompt Generator
- Prompt Gen
- EZprompt

Там кстати телега обновление выпустила, всякие ништяки типа цитат, блоков кода и т.п. Буду теперь к постам это все применять. Не забудьте обновиться, чтобы у вас тут все красиво выглядело, а не как гавно.

Пойду дальше диван давить, да киношки смотреть. Наконец-то что-то похожее на выходной. Увидимся!

tags: #linux #services
—
💩 @bashdays

Вчера посмотрел спокойной ночи малыши и отрубился, каково было моё удивление, что в 6 утра не пришлось вставать и отвозить ребенка в школу. Каникулы же! Эхх… Ладно, а у нас бесконечные рабочие будни.

Сегодня обсудим интересную команду в bash, которая называется enable. Эта команда включает или отключает встроенные команды оболочки. Чтобы проще было понять эту шляпу, разберем на практике.

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

Запускаем:

type test

И видим выхлоп: test is a shell builtin. То есть используется команда test встроенная в оболочку. А не та что лежит на пути в test: /usr/bin/test. А как нам воспользоваться дисковой версией этой утилиты? А вот так:

enable -n test
type test 

И мы получаем уже такое: test is /usr/bin/test. Получается мы сделали некое переключение. И по факту используем разные версии test.

Чтобы включить обратно встроенную команду test в оболочке, выполняем:

enable test

Так окей. Что еще можно с этим интересного сделать? А можно подгрузить расширения поставляемые с оболочкой. Некие плагины, экстеншены. Для этого эти экстеншены нужно установить (если у тебя их нет:

apt/yum install bash-builtins

Все это дело установится в папку /usr/lib/bash/. В ней будут всякие mkdir, rm, sleep и т.п. По сути это те же дисковые команды, только экстеншены для оболочки.

Для начала узнаем дисковую версию команды mkdir:

mkdir --version

Ага, есть: mkdir (GNU coreutils) 8.32

Теперь загружаем экстеншен в оболочку:

enable -f /usr/lib/bash/mkdir mkdir
mkdir --version

Хе! -bash: mkdir: --: invalid option

Теперь запускаем:

type mkdir

И получаем: mkdir is a shell builtin, то есть теперь mkdir используется не системный (дисковый), а тот что подгружен в оболочку bash.

Например, ты снес все системные бинарники и у тебя есть только bash. Через подгрузку экстеншенов можно без проблем обслуживать свою операционную систему, даже если в системе пропали всякие mkdir и т.п.

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

lsof +fg -p $$

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

С версии 4.4 в bash появилась переменная BASH_LOADABLES_PATH, с помощью нее ты можешь задать путь для поиска экстеншенов. Тогда при подгрузки этих модулей, не нужно будет использовать полные пути.

BASH_LOADABLES_PATH=/usr/lib/bash/
enable -f sleep sleep

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

Ну либо в ситуации когда ты случайно снес бинарники и нужно как-то админить и восстанавливать систему. В общем тут всё рассчитано на полный полет твоей фантазии.

Развлекайся )

tags: #linux #bash #utils
—
💩 @bashdays

Подсмотрел тут у товарища интересную идею с итогами по постам за прошлый месяц. Типа ТОП лист самого интересного, что прям со свистом залетело в умы. Попробую и я такое провернуть. Поехали!

Больше всего просмотров:

- Про SheBang и интерпретатор (7350)
- Шаринг файлов с серверов в телеграм (6834)
- Утилита JC (6545)
- Форматер длинных строк (6469)
- Приколы с утилитой shopt (6379)
- Потрошим HereDoc (6300)
- Комбайн для архиваторов (6239)
- Лучший способ читать переменные из файла (6186)
- Как перелезть на VIM и не помереть (6089)

Больше всего пересылок:

- Изолируем пользователя в chroot (177)
- Компилируем bash скрипт в бинарный файл (136)
- Делаем красивые диалоговые окна (135)
- Игруля Rick & Morty Quest (132)
- Про flock и долгоиграющие скрипты (131)
- Фреймворк для тестирования bash скриптов (120)
- Уничтожаем процесс через порт с помощью Kill Port (113)

Больше всего комментариев и лайков:

- Strace или что запускает программа
- Про CTRL+D и завершение сессий
- Bash Prompt Generator
- Чем отличается rm от unlink

Ну и не забываем, что есть навигация по тэгам (в закрепленном сообщении). Да, очень хорошо выстреливает рубрика #debug. Надо наверное за прошлые месяцы тоже будет такую табличку сделать.

tags: #итогимесяца 10/23
—
💩 @bashdays

О чо у меня есть, офигительная шпаргалина!

n.e. в колонке означает not existing (не существует)

Давай разберем:

command > file.txt

Поток вывода перенаправлен в файл, в терминале его не видно. Если файл существует, он будет перезаписан.

command >> file.txt

Поток вывода перенаправлен в файл, в терминале его не видно. Если файл существует, то новые данные добавятся в конец файла.

command 2> file.txt

Поток ошибок перенаправлен в файл, в терминале его видно. Если файл существует, он будет перезаписан.

command 2>> file.txt

Поток ошибок перенаправлен в файл, в терминале его не видно. Если файл существует, то новые данные будут добавлены в конец файла.

command &> file.txt

Поток вывода и поток ошибок перенаправлены в файл, в терминале их не видно. Если файл уже существует, то он будет перезаписан.

command &>> file.txt

Поток вывода и поток ошибок перенаправлены в файл, в терминале их не видно. Если файл уже существует, то новые данные будут добавлены в конец файла.

command | tee file.txt

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

Команда tee в Linux считывает стандартный ввод и записывает его одновременно в стандартный вывод и в один или несколько подготовленных файлов.

command | tee -a file.txt

Поток вывода скопирован в файл, он виден в терминале. Если файл уже существует, то новые данные будут добавлены в конец файла.

(*)

В Bash нет сокращенного синтаксиса, позволяющего передавать только StdErr второй команде, что было бы необходимо в данном случае в сочетании с tee для завершения операции.

command |& tee file.txt

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

command |& tee -a file

Потоки вывода и ошибки скопированы в файл, в терминале их видно. Если файл уже существует, то новые данные будут добавлены в конец файла.

Вот такие пироги. Подробнее стандартные потоки разберем в следующих постах, многие их не понимают. Изучай.

tags: #linux #sheets #bash
—
💩 @bashdays

Пока я готовлю разжеванный пост про стандартные потоки ввода-вывода, закину тебе еще одну игрулю для изучения оболочки через геймификацию.

Автору изобретения, капец как надоело бодаться с первокурсниками, у которых вместо головы - палено. Вот он и изобрел этот тренажер, чтобы эти тупни сами во всем разбирались проходя увлекательные миссии.

Называется эта поделка GameShell.

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

Русского языка по понятным причинам в этот тренажер не завезли, но будет лишний повод подтянуть английский/французский/эсперанто.

GameShell запустится на любой операционке Linux/macOS.

Устанавливать так:

sudo apt install gettext man-db procps psmisc nano tree bsdmainutils x11-apps wget

$ wget https://github.com/phyver/GameShell/releases/download/latest/gameshell.sh
$ bash gameshell.sh

Вот и все. Цель игры: Выполнять миссии, продвигаться вперед и сохранить рассудок. Если соберешь все яйца, в конце покажут мультик, но это не точно.

🐱 Страница проекта на github

tags: #linux #games
—
💩 @bashdays

Привет. Я часто использую set -xve для отладки bash скриптов. Вообще это мастхев фича именно на момент, когда ты что-то создаешь. Ведь не всегда логика может работать правильно (в моих случаях так и есть), а с set -xve, ты вовремя можешь увидеть все значения переменных и т.п. не используя мусорные конструкции в своих поделках типа echo «Error in function xxx».

Конструкцию с set я обычно вставляю в shebang либо после, отдельным сетом:

#!/bin/bash -xve

set -xve

<script body>

Ключики команды set:

x = Выводим команды и их аргументы по мере их выполнения.
v = Выводить строки ввода командной строки по мере их считывания.
e = Немедленный выход, если команда завершается с ненулевым статусом.

Окей. Как-то дебажил один большой и сложный скрипт на овердофига строк. В какой-то момент скрипт завершался с ошибкой. В режиме отладки set -xve я видел, где он упал. Но мне хотелось знать — а на какой строке это произошло? Номера строк увы не выводятся, а по поиску и визуально искать - ну такое себе.

Эхх, одна задача превратилась в другую. В общем решил разок упороться и проресерчить этот вопрос, на будущее так сказать. По итогу получилось так:

Изменяем PS4 и добавляем вывод номера строки во включенный дебаг режим:

#!/bin/bash -xve

PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

bar=10
echo ${bar}
echo $((6 + 6))

После выполнения скрипта, получаем нумерацию строк:

bar=10
+(./script.sh:6): foo=10
echo ${bar}
+(./script.sh:7): echo 10
10
echo $((6 + 6))
+(./script.sh:8): echo 12
4

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

Ну а чтобы добавить визуального оргазма, экспортируем PS4 так:

PS4='\033[0;33m+(${BASH_SOURCE}:${LINENO}):\033[0m ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

Происходит подкрашивание запускаемых строчек.

С помощью PS4 мы можем отладить shell-скрипт, задав при его выполнении set -x, что позволяет выводить каждую команду, а затем ее результаты. Перед каждой командой ставится знак +, эту строку подсказки "+" можно изменить, определив переменную PS4.

Берите на вооружение. Хорошего дебага и с пятницей. Берегите себя!

tags: #linux #bash #debug
—
💩 @bashdays

Доброе утро и привет!

В этот прекрасный выходной я научу тебя как узнать имя функции из самой функции.

#!/bin/bash

deploy() {
  # здесь хочу получить "deploy"
}

Для получения имени функции из самой функции, можно воспользоваться переменной ${FUNCNAME[*]}.

Элемент с индексом 0 это имя любой выполняемой функции в данный момент. Ну а тот что имеет самый большой индекс, в моем случае это 1 (так как функция у меня одна) будет называться main.

deploy() {
    echo ${FUNCNAME[0]}
}

Выведет название функции: deploy

Переменная FUNCNAME существует только во время выполнения скрипта. Если самостоятельно задать переменную FUNCNAME, это ничего не даст и все равно выведется эталонное имя функции.

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

Например:

exp1() {
    echo ${FUNCNAME}
}

exp2() {
    echo ${FUNCNAME[*]}
}

Первая функция выведет: exp1, а вторая выведет весь массив функции: exp2 main.

Вообще не обязательно указывать индекс, оно будет корректно работать и так. Это больше как кодстайл. Как в конце строки ставишь точку с запятой, которая не влияет на функционал программы и вообще никак не интерпретируется.

Ну а в zsh это штука называется funcstack, это тот же массив всех функций скрипта.

deploy() {
   echo $funcstack[1]
}

Еще переменная FUNCNAME используется с BASH_LINENO и BASH_SOURCE, но про это уже можешь глянуть в официальной документации, как там вся эта магия происходит.

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

BASH_LINENO - переменная, содержит номер строки на которой произошла ошибка в текущем скрипте.

Вечером подвезу еще ништяков. Пойду маркировать интеграции, разгребать бухгалтерию, да готовить закупы на следующую неделю. Еще единомышленников немного сюда приведем. Давай пять, увидимся!

tags: #linux #bash #debug
—
💩 @bashdays

Сейчас за кружкой чая, кореш задал вопрос - Ромыч, а расскажи мне, что означает 2>&1? Хм… Нашел время, а так хорошо сидели.

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

Как мы знаем, потоки вывода имеют файловые дескрипторы:

stdout = 1 (общий поток вывода)
stderr = 2 (поток с ошибками)

Получается (2>&1) = stderr > stdout. То есть направляем поток с ошибками, в стандартный поток вывода. Ошибки будут выводиться на экран в терминале.

Логичным было бы сделать конструкцию: 2>1. Но увы, эта схема отработает другую логическую операцию. Поток с ошибками stderr будет писать все данные в файл, у которого название будет 1.

Вот для этого и требуется указать символ & (амперсанд) перед stdout. Это будет интерпретировано как файловый дескриптор, а не обычный файл.

А почему тогда не &2>&1. Логично же? Но нет! Символ & интерпретируется как файловый дескриптор только в контексте перенаправления.

Операция command &2>&1 анализируется так: command & 2>&1. То есть команда command будет выполнятся в фоновом режиме. А затем начнет выполнятся команда 2 с перенаправлением на стандартный вывод stdout.

Вот такие дела. А еще есть альтернатива с оператором |&.

|& это сокращенный вариант от 2>&1 |

Пример:

script.sh |& tee -a /var/log/script.log

Все что script.sh выведет в потоки stdout и stderr, будет перенаправлено в файл script.log.

В официальной документации этот момент хорошо расписан, но я расписал тебе еще проще.

Как говорится — мы из рощи, мы попроще! Всё, не смею тебя больше отвлекать, спасибо за внимание. Увидимся скорее всего в понедельник или вторник. Если чо пиши в чатик, мы там завсегда тебе рады!

tags: #linux #bash
—
💩 @bashdays

Привет, друзья! Есть у меня какой-то долгоиграющий скрипт, который я по дурости запустил в терминале, без nohup и применения screen. Ждать завершения скрипта не вариант, но и завершать его принудительно нельзя. Как быть? Сейчас покажу, поехали.

Сделаем подопытный образец, который в цикле будет писать в файл числа от 1 до 10000, чтобы визуально понимать что происходит. Ну и паузу впендюрим 2 секунды, для чистоты эксперимента.

#!/bin/bash

for i in {1..10000}
do
 echo $i >> /tmp/log.txt
 sleep 2
done

Запускаем, ага. Теперь открываем второй терминал и пишем:

tail -f /tmp/log.txt

Видим как файл log.txt постепенно наполняется циферками.

Всё прекрасно. Что нужно сделать дальше. А дальше жми сочетание клавиш ctrl+z в первом терминале, где ты запустил скрипт.

Комбинация клавиш Ctrl + Z посылает процессу сигнал, который приказывает ему остановиться. Это значит, что процесс остается в системе, но как бы замораживается.

Ловим такое:

[1]+ Stopped ./script.sh

Видим что скрипт остановил свою работу. А во втором терминале с tail, цифры перестали заполнять файл log.txt. Ключевое слово - остановил, но не прекратил. Окей, мы на верном пути.

А теперь в первом терминале запускай команду bg, в ответ ты увидишь такое:

[1] + ./script.sh & 

Видишь в конце закорючку &, наталкивает на мысли? 🤒

Команда bg предназначена для возобновления исполнения остановленной задачи в фоновом режиме в командных оболочках.

Скрипт продолжил работу в фоне, с того момента где ты его приостановил. Идем во второй терминал с tail и видим, что цифры продолжили заполнять файл.

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

Запускаем финалочку:

disown %1

Команда disown блокирует отправку системного сигнала SIGHUP с помощью командной оболочки и исполняющемуся в фоновом режиме процессу при завершении работы командной оболочки.

Теперь в первом терминале пишем exit либо просто закрываем его нахрен. Ха! А во втором терминале работа скрипта продолжается. Магия!

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

Наверное есть еще варианты провернуть подобное. Я показал способ которым пользуюсь сам.

Ключевые слова для самостоятельного гугления: bg, fg, jobs, disown, nohup.

Да, после того как нажал ctrl+z, можно все откатить назад, запускаешь команду fg и ловишь флешбек.

Такие вот дела. Хорошего тебе вторника и не болей!

tags: #linux #bash
—
💩 @bashdays

Всем привет кого не видел и новеньким. Нас тут уже овер 10к единомышленников, растем!

Вопрос из зала — я бывший java разработчик, подался в девопсы, теперь неспешно изучаю bash. Подскажите, если какая-то альтернатива конструкции try/catch?

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

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

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

Например:

command1 || command2

Если первая команда вывалит ошибку, то отработает вторая команда. Ну чем не try/catch, Даже лучше! Правда концепция работы не такая как в других языках.

На практике это выглядит так:

false || echo "error, returned false"

Сейчас сработает catch и выведет «error, returned false», так как команда false всегда возвращает ошибку. Статус: exit 1.

А если false заменить на true, но сработает try и в терминале ничего не отобразится. Бесподобно.

Итоговая конструкция будет такой:

#!/bin/bash

{ # try
    echo "hello bashdays"
    false
    
} || { # catch
    echo "error, returned false"
}

Для catch можно сделать отдельную функцию. Которая будет автоматически включать режим дебага (sex -x) либо какие-то другие свистоперделки для отладки.

Вообще это больше относится к костылям и подобное можно реализовать с таким же успехом на IF’ах. А можно банально проверять статус выхода, если > 0 то кирдык.

Я такие конструкции не использую, максимум втыкаю в начала скрипта set -e. Если статус команды будет > 0, то немедленно всё выпадет в осадок.

Тут нет правильных и неправильных решений. Как говорится если работает, то уже хорошо. Остальное детали.

Если есть чего добавить, велком в комментарии. Возможно у тебя есть секретный модуль для bash с try/catch.

tags: #linux #bash
—
💩 @bashdays

Привет. Не будем нарушать воскресных традиций. Утреннее чтиво.

Давай покумекаем, чем отличаются файлы .bashrc .bash_profile .profile и т.п.

Вообще про это особо никто не задумывается, если что-то требуется сделать, обычно запихивают всё в .bashrc. Но почему именно туда? А нахрена тогда нужен .profile?

Основное различие этих конфигурационных файлов заключается в том, что некоторые из них читаются только оболочками входа (login). Например, при входе в систему с другого хоста или при входе в текстовую консоль локальной unix-машины. Используются файлы .login .profile .zlogin. Зависит от того какая у тебя оболочка.

Далее идут конфигурационные файлы, которые читаются «интерактивными» оболочками. То есть подключенными к терминалу или псевдотерминалу. Это файлы с именами .bashrc, .tcshrc, .zshrc и т.д.

Файл .bashrc читается только интерактивной и non-login оболочкой, поэтому большинство людей в конечном итоге инклудят в файле .bash_profile чтение файла .bashrc, например:

[[ -r ~/.bashrc ]] && . ~/.bashrc

Другие оболочки ведут себя по-другому. Например, в zsh, файл .zshrc всегда читается для интерактивной оболочки, независимо от того, является ли она login или нет.

А файл .profile, это просто сценарий входа в систему. И изначально использовался в /bin/sh. Оболочка Bash, будучи обратно совместимым с sh, будет читать .profile, если он конечно же существует.

Пример файла .profile

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

Как видим, при login’е заинклудится файл .bashrc.

Классически ~/.profile используется в Bourne Shell. И вероятно, поддерживается Bash как устаревшая мера. Опять же ~/.login и ~/.cshrc использовались оболочкой CShell (csh).

В дистрибутивах семейства Debian сначала выполняется .profile, а потом уже .bash_profile. А вот в дистрибах производных от RHEL, сначала выполняется .bash_profile, а уже потом .profile. Ну вот прям каша! 

Короче как обычно развели зоопарк, одно читает другое, чтобы заработало третье. Масло-масляное. А есть же еще всякие .environment, у которого ноги растут из Korn Shell (ksh).

Вот по этой причине никто особо и не вникает, почему все манипуляции обычно производятся в файле .bashrc. Этот файл обычно есть везде и всегда, а большего и не нужно.

В документации bash хорошо объясняется, при каких обстоятельствах читается каждый файл. И поведение на разных машинах в целом одинаково.

Выжимка из man bash:

/bin/bash - The bash executable
/etc/profile - The systemwide initialization file, executed for login shells
/etc/bash.bashrc - The systemwide per-interactive-shell startup file
/etc/bash.bash.logout - The systemwide login shell cleanup file, executed when a login shell exits
~/.bash_profile - The personal initialization file, executed for login shells
~/.bashrc - The individual per-interactive-shell startup file
~/.bash_logout - The individual login shell cleanup file, executed when a login shell exits
~/.inputrc - Individual readline initialization file

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

tags: #linux #bash
—
💩 @bashdays

Давай повелосипедим и напишем таймер на со-процессах, без использования каких-то внешних команд типа sleep и т.п.

#!/bin/bash

coproc read 
read -t 0.10 -u "${COPROC[0]}"
echo 'new velosiped' 
read -t 11 -u "${COPROC[0]}"
exit

1. Создаем фоновый со-процесс read
2. Спим 0.10 секунды
3. Выводим на экран new velosiped
4. Опять спим, но уже 11 секунд
5. Выходим

За указания задержки, как раз отвечает параметр -t. А параметр -u говорит что чтение данных нужно осуществлять с файлового дескриптора запущенного в фоне со-процесса. Белиберда? Еще какая!

В sleep, кстати тоже можно указывать миллисекунды: sleep 0.10

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

Чтобы запустить со-процесс, используется зарезервированное слово coproc. Доступ к этому со-процессу осуществляется посредствам массива COPROC.

${COPROC[0]} - для записи
${COPROC[1]} - для чтения

В реализации такого таймера есть и подводные камни. Таймер может отставать как механические часы, это зависит от загруженности самой системы.

Если запустить одну команду coproc read, на экран выведется PID запущенного в фоне процесса [1] 126594. Чтобы посмотреть список запущенных в фоне команд, выполняем jobs и видим список:

[1] Running coproc COPROC read &
[2] Running coproc COPROC read &
[3] Running coproc COPROC read &

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

Еще пример:

coproc awk '{print $2;fflush();}'
echo bom bim bom >&${COPROC[1]}
read -ru ${COPROC[0]} var
echo $var

По итогу получаем вывод на экран, слово: bim

Давай попробуем попроще:

coproc (echo $(whoami))
read -r user <&"${COPROC[0]}"
echo $user

1. Создаем со-процесс, который в фоне выполнит whoami
2. Прочитаем в переменную user, то что вывел со-процесс
3. Выводим на экран, у меня отобразилось root

Фуф, тут вроде более понятно получилось объяснить. Ну а если не понял, значит оно нахер тебе и не нужно.

Короче без бутылки тут не разобраться, это из оперы «высший пилотаж» и брейнфак.

Зачем это нужно и где применять? Понятия не имею. Я обычно не лезу в со-процессы, это усложняет скрипт, а коллеги которые не в теме, вообще не смогут его поддерживать.

Ну и на закуску, совсем уж упороться:

Несколько команд, которые помогут понять, как вся эта шляпа реализована.

coproc read
echo "${COPROC[@]}"
ls -l /proc/$$/fd | grep 'pipe'
ls -l /proc/$COPROC_PID/fd | grep 'pipe'

1. Создаем со-процесс
2. Выводим содержимое массива COPROC
3. Выводим каналы текущей оболочки.
4. Выводим каналы со-процесса.

Смотрим на имена, биты разрешений (r/w) ссылок и на что они указывают.

Как сказал один западный эксперт:

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

Вот такие пироги, изучай.

tags: #linux #bash
—
💩 @bashdays

Доброе всем! Я как ценитель всяких бумажных Bullet Journal и подобных ежедневников, в какой-то момент перегорел. Стало лень писать ручкой, заполнять задачки и планировать рабочий день. Не знаю по какой причине это произошло.

Но скорее всего по причине — если ты спланировал свой день, 100% все пойдет попизде не по плану. Это как со скрам спринтами, спланировали спринт, тут же прибежала озабоченная обезьяна и насувала в кабину «очень» срочных задач. Понятно дело, это на подсознании отлично демотивирует.

Но без личного таск-трекера опять же никуда. Носить в голове 100500 задач, рабочих, бытовых и т.п. не вариант. Сейчас ты помнишь, что нужно было оплатить домен, а через секунду уже не помнишь. Классика.

Я так недавно промотал оплату корпоративного VPN и пришлось в срочном порядке платить со своей личной карты. Естественно потом мне бабки никто не вернул. Бюрократия. Игра не стоит свеч.

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

TaskWarrior это консольный трекер-задач с открытым исходным кодом. Черношляпы еще его называют ТуДу-ВуДу лист для хакеров.

Короче, открываем консольку…

У меня вообще с этим отлично реализовано в iTerm. Консолька открывается в Drop-down режиме по нажатию F1. То есть сверху вниз, поверх всех окон выезжает мой основной рабочий инструмент. Ну и также закрывается. Привык, ОЧЕНЬ удобно! Под линуксы и винду такое тоже реализуемо и есть из коробки. Отдельный пост про это надо будет запилить.

Давай создадим в TW первую таску:

task add "Написать пост про taskwarrior"

Всё! Задачка в бэклоге и про нее уже не забудешь, можно смело выкидывать из головы и торжествовать.

Конечно же предварительно taskwarrior нужно установить, есть под все операционки и дистрибутивы. Дока по установке тут. Ставится на уровне пакетных менеджеров, но можно и через исходники скомпилировать если ты любитель прекрасного.

Как говорится на этом можно и закончить. Но хотелось бы еще посмотреть список всех задачек, которые мы создали. Для этого фигачим:

task ls

И получаем желаемый список Ну а чтобы пометить таску как выполненную, делаем:

task done 1/2/3/4/5

Подставляем индекс таски, которую нужно закрыть. Всё! Это основное. Простота и удобство! Не думай что TW на столько ущербен, там из коробки просто нереальный функционал. Но я использую наверное процента два от всего возможного.

Дополнительно у меня создано 2 проекта, home и work. По ним раскидываю задачи, которые относятся к домашним делам и рабочим. Чтобы было проще ориентироваться и выводить нужные на экран.

Чтобы синхронизировать заметки и задачи между устройствами, нужно поднять свой ламповый сервер. Будет единая точка входа с базой данных. А там уже цепляйся к нему хоть с писюка хоть с андроида/ios, и крути педали. Удобнее конечно через docker-compose все поднимать.

Для удобства я сделал себе несколько алиасов, теперь мне не нужно каждый раз писать task и название проекта.

alias th="task project:home add "
alias tw="task project:work add "
alias tlh="task project:home ls "
alias tlw="task project:work ls "

В общем в TW полный минимализм и отличная кастомизация для всех любителей консольных штук. Еще можно настроить цвета, приоритеты, поглядеть отчеты и многое другое. Но мне хватает коробочного варианта. В общем всем советую потыкать.

💩страница проекта
🐱 страница на гитхабе
💩 клиент для андроида и тут
💩 клиент для айфона

Как это выглядит визуально, можешь глянуть тут, подзалил нативно картичночки. А тут крутой sheets по tw.

Ладно, убежал. Если бухгалтерию разгребу, вечерком чего-нибудь забашим или обсудим!

tags: #linux #utilites #рабочиебудни
—
💩 @bashdays

Тут недавно у нас в чатике пролетал способ как скрыть процессы в Linux от других пользователей. Пожалуй этот момент стоит поподробнее просветить и тут. Тема интересная.

К примеру есть многопользовательский сервер. Юзера конектятся к нему по ssh. И я не хочу чтобы какой-нибудь там Василий Волоёбович знал, что у меня запущена порнокачалка.

По идее если запустить pstree, ps, htop и др. То мы увидим процессы не только свои, но также системные и пользовательские.

Чтобы скрыть свои процессы от других пользователей, всего лишь нужно перемонтировать /proc с опцией hidepid.

Работает только с пользователями, рут будет по-прежнему в курсе запущенной порнокачалки.

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

Параметры которые можно задать:

hidepid=0 - Включена по умолчанию, все видят всё, полный доступ к /proc/PID/.

hidepid=1 - Разрешает обращаться к информации только о своих процессов. Часть файлов в каталоге /proc/PID/ защищена от любопытных морд.

hidepid=2 - Это тот же самый hidepid=1 + всё в /proc/PID будет невидимо для других пользователей. Граница на замке.

Чтобы убедиться, что ты видишь процессы других, запусти от обычного пользователя например htop. В левой колонке будут имена пользователей, root, грут, пруд, фрукт, daemon, syslog и т.п.

Давай теперь закроем этот «бэкдор».

Запускаем от рута:

mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

Теперь снова запускаем от обычного пользователя htop и наблюдаем интересную картину маслом. Портянка из процессов пропала, у меня осталось лишь 2 штуки, bash и htop. Красота!

Естественно после ребута сервера, вся эта красота сгинет. А чтобы этого не произошло, зафигач монтирование /proc в fstab.

Вставляем в /etc/fstab

proc /proc proc defaults,nosuid, nodev, noexec,relatime,hidepid=2 0 0

Вот и всё. Но есть одно НО. Встречаются приложения которые могут отвалиться. Для этого нужно захотфиксить маунт с опцией gid=VALUE.

Значением gid параметра может быть имя группы в системе, членам которой доступ к процессам будет разрешён. И затем маунтить /proc таким образом:

proc /proc proc defaults, hidepid=2, gid=bashdays 0 0

Добавляем пользователя от имени которого будет работать приложение/демон в эту группу и проверяем — если всё сделано верно, то зафакапленное приложение заработает как обычно.

Такие дела. Изучай. На связи!

tags: #linux #utilites
—
💩 @bashdays

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

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

Софтина называется VHS. Позволяет ЧЕРЕЗ КОД записать gif файл.

VHS написана на модном golang. Для начала устанавливаем. Есть под все операционки, в документации найди свой дистрибутив и накопипасти в терминал.

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

Создаем файл сценария bashdays.tape

vim bashdays.tape

И пишем код:

Output bashdays.gif
Require echo

Set Shell "bash"
Set FontSize 32
Set Width 1920
Set Height 1080

Type "echo 'Hello this is BashDays'" Sleep 500ms  Enter
Type "apt install -y nginx" Sleep 500ms Enter

Sleep 5s

Думаю тут все интуитивно понятно, откроется оболочка bash, настроятся шрифты, высота, длиннота и сообщение которое будет напечатано. Либо команда, которая будет выполнена. Настроек там дофига, но как обычно 90% никем не используются.

После того как сценарий готов, запускаем:

docker run --rm -v $PWD:/vhs ghcr.io/charmbracelet/vhs bashdays.tape

Наблюдаем за процессом создания и на выходе получаем файл bashdays.gif. В котором будет вывод строки через echo и процесс установки nginx.

Получившийся gif файл можно не отходя от кассы сразу зашарить на какой-то расшаренный сервер.

Вот такой командой:

docker run --rm -v $PWD:/vhs ghcr.io/charmbracelet/vhs publish bashdays.gif

По итогу получишь прямую ссылку вида: https://vhs.charm.sh/vhs-62gl16v.gif

Ну а дальше уже втыкай свои гифки в корпоративные wiki, или куда там ты их втыкаешь. Короче штука ОФИГИТЕЛЬНАЯ. Всем рекомендую!

🐱 Сраница проекта на github

Всех с пятницей, хороших предстоящий выходных и береги себя! 🤩

tags: #linux #utilites
—
💩 @bashdays