Bash Days | Linux | DevOps

Мастхэв для инженеров инфраструктуры, плюс для программистов 26 февраля стартует 6 поток Apache Kafka для разработчиков. Это углублённый курс с практикой на Java или Golang и платформой Spring+Docker+Postgres. Мы расскажем и покажем, как выйти на новый уровень владения инструментом. Что вы получите: 👉 Узнаете , как использовать Kafka при создании приложения. 👉 Решите реальные бизнес-кейсы. 👉 Получите типовые шаблоны проектирования: они облегчат разработку на начальном этапе. 👉 Узнаете о большинстве частых ошибок, и научитесь их избегать. Что в программе? В курсе 28 онлайн-уроков, готовые стенды, много-много практики и закрытый чат с кураторами. Коротко о программе: ➡️ Терминология. В подробностях и с примерами расскажем, что такое нода, датацентр, кластер, ZooKeeper, консумер, топик и так далее. ➡️ Как выстроена архитектура Kafka. ➡️ Основы брокера. Разберем, как создать топик, настроить продюсер и консумер. ➡️ Как выстраивать архитектуру между микросервисами. ➡️ Наиболее распространенные проблемы при использовании приложения. ✔️ Регистрируйся на сайте и начни учиться бесплатно! Записаться можно по ссылке. Реклама. ООО «Слёрм» г. Лиски, ОГРН 1193668020545

Помнишь я писал про shellcheck, который проверяет Bash скрипты на синтаксические и подобные ошибки. Ну так вот, у интерпретатора Bash есть подобный функционал прям из коробки. Суть - проверить скрипт на ошибки, до запуска. Перед запуском скрипта, добавь флаг -n и оно тебе скажет, накосячил ты или нет. Конечно коробочный вариант не такой гибкий как shellchek, но зато ничего не нужно устанавливать лишнего. Это как nginx -t перед его ребутом. Зачем ставить что-то внешнее, если это уже предусмотрено в самой программе. Ну только если расширить функционал и получить больше плюшек. А если работаешь с гитом, можешь сделать pre-hook и гавно в репу уже не улетит (но если постараешься, то улетит):

bashErr=$(find src/ -type f -name '*.sh' -exec bash -n {} \;  2>&1 > /dev/null)
if [ -n "$bashErr" ]; then 
    echo "$bashErr"
    exit 1
fi

После запуска этого хука проверяются все * .sh скрипты в папке src. Пример скрипта с ошибкой:

echo "Hello Bashdays
exit 0

Хуй Хук выдаст тебе сообщение src/script.sh: 7: Syntax error: Unterminated quoted string и запретит (коммитить, пушить в мастер). Нечто подобное было прикручено к puppet очень давно в одной студии, был какой-то внутренний линтер на хуке гита, но хлебнул я знатно с ним. Мне пушить, а он на какие-то фантомные пробелы орет падла. Короче как только встал у руля, избавился и от этого вонючего паппета, от хуков и от команды. Ну или как вариант можно включать set -u, например если переменную не объявил и попытался где-то её использовать.

set -u включает режим обработки неустановленных переменных (также известный как режим nounset). Когда этот режим включен, обращение к неустановленной переменной приведет к ошибке выполнения скрипта.

set -u

echo "Переменная VAR: $VAR"

./script.sh: line 3: VAR: unbound variable

Или так:

set -o noexec

Включает режим noexec (режим «нет выполнения»). Когда этот режим включен, скрипт не будет выполняться, а только проверяться на синтаксические ошибки. В общем много вариантов есть, чтобы проверить не запуская. А завтра кстати внеплановая пятница! Ждем ждем… tags: #bash — 💩 @bashdays

🤔Что происходит на рынке баз данных в свете импортозамещения? 🔥Обсудим этот злободневный вопрос на бесплатном открытом уроке 4 марта вместе с Сергеем Окатовым — руководителем управления разработки, Fullstack-разработчик с опытом >10 лет ✅Если вы бэкенд-разработчик, аналитик, тимлид, архитектор или занимаетесь вопросами миграции, этот урок — для вас. Мы обсудим мировые тенденции в сфере баз данных, рассмотрим предложения от отечественных производителей, а также сравним их с зарубежными аналогами. Разберемся, как обстоят дела на российском рынке и какие проблемы требуют решения. 👉🏻Этот открытый урок – хороший шанс расширить знания и получить свежие инсайты о рынке баз данных. Больше актуальных знаний ждут вас на онлайн-курсе OTUS “NoSQL”. Осталось меньше половины мест. Курс можно приобрести в рассрочку. 🤝Чтобы записаться на открытый урок, пройдите вступительный тест! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

А спорим ты не знаешь чем отличается:

var=$(command)

от

var=`command`

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

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

Если на чистоту, то эти два примера ничем не отличаются, логика работы будет одинакова. Выполнится какая-либо команда (command) и ее результат запишется в переменную var.

Эти штуки, кривые кавычки, называются backticks = обратные палки/знаки или gravemarks = надгробия.

Второй вариант с надгробиями звучит как-то прикольнее, чем какие-то палки-копалки. А в чём, тогда подвох? Да всё просто - gravemarks (надгробия) морально устарели и в бест-практиках нынче $(command). Ну и конечно же при использовании надгробий будет много геморроя например с вложенными командами и экранированием. Вот пример:

list=$(ls -l $(cat bashdays.txt))

либо

list=`ls -l \`cat bashdays.txt\``

Очевидно что первый вариант предпочтительнее, чем второй. Предпочтительнее в плане читаемости и ошибку в синтаксисе ты вряд ли допустишь. Ведь чем сложнее будет команда, тем больше этих надгробий придётся использовать. Возникает проблема вложенности. Ну и порой использование gravemarks влияет на результаты:

A="A_VAR"
echo $(echo "\$A")
echo `echo "\$A"`

Вроде две одинаковые команды, а выведут разный результат:

$A
A_VAR

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

echo `echo "\$A"`

В результате получим вывод на экран: $A как и в первом варианте с $(). Вот такие пироги. Так что если до сих пор используешь gravemarks, посмотри в сторону $(), оно как бы правильнее. Но опять же, со своим уставом куда-то там не ходят. Выбор каждого. Ладно. Давай краба, увидимся! tags: #bash — 💩 @bashdays

Как избежать банальных ошибок на тех. интервью? Об этом рассказывает Илья Шишков — эксперт по C++ и разработчик с 20-летним стажем, спикер и ведущий IT-конференций, за плечами которого 11 лет работы в Яндексе! Еще он основатель трех проектов, которые комплексно закрывают вопрос собесов в IT: • «Пояса по C++» • «Алгоритмический фундамент программиста» • «Выше вилки» А в личном канале Илья «без прикрас» делится своими косяками внушительным опытом и подробно объясняет, как проходили его собесы на самом деле. И даже с юмором (иногда). Учиться на чужих ошибках всегда проще! А если хотите узнать настоящую «внутрянку» тех. собесов — подписывайтесь и смотрите закреп канала, чтобы быть во всеоружии! 🔜 Тык сюда Реклама. ИП Шишков И.И. ИНН: 575206903941, erid: 2VtzqwiCcS5

Тадам! Сегодня научимся определять, отправляется ли стандартный вывод скрипта в терминал либо передается с помощью pipe в другой скрипт/утилиту. Чтобы стало понятнее, нужно читать дальше. Есть у меня некий Bash скрипт, пусть будет таким:

echo "Hello Bashdays Welcome"

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

bold=$(tput bold)
normal=$(tput sgr0)

echo "Hello ${bold}BashDays${normal} Welcome"

Этот скрипт выведет строку Hello Bashdays Welcome, где слово Bashdays будет жирным (bold). Дальше я хочу, чтобы при использовании pipe, слово BashDays НЕ выделялось жирным. То есть если запустить скрипт самостоятельно, без использования пайпов, то текст будет жирным. Если скрипт запущен через пайп, то текст остается нормальный.

./script.sh Hello Bashdays Welcome ./script.sh | cat Hello Bashdays Welcome

Пригодится например, чтобы не передавать утилитам всякие ненужные управляющие символы, а на экран выводить опрятную и ухоженную девочку. Про управляющие символы можешь почитать в этом посте. Давай мутить В POSIX оболочках существует флаг -t, с помощью которого можно задетектить файловый дескриптор. Если файловый дескриптор fd = True, то скрипт запущен самостоятельно в терминале. Дескриптор fd может принимать значения:

0 - стандартный ввод
1 - стандартный вывод
2 - стандартная ошибка

Пишем скрипт с логикой:

bold=$(tput bold)
normal=$(tput sgr0)

if [ -t 1 ] ; then
    echo "Hello ${bold}BashDays${normal} Welcome"
else.
    echo "Hello BashDays Welcome"
fi

Запускаем:

./script.sh Hello BashDays Welcome ./script | cat Hello BashDays Welcome

Видим сработал детект. Скрипт самостоятельно определил, как он был запущен и вывел на экран, то что требуется. Флаг -t справедлив не только для Bash, он будет работать во всех POSIX оболочках. Вот такие вот интересные кейсы порой приходится решать, благо всё это давно придумано за нас, главное знать про эту срань. Ну теперь и ты про неё знаешь. Хорошего дня, увидимся! tags: #bash — 💩 @bashdays

Аренда сервера с GPU для работы с 3D-моделированием, рендерингом и машинным обучением. Соберите себе мощный сервер для сложной аналитики, работы с графикой и обучения нейронных сетей. В Selectel доступен большой выбор видеокарт как в облаке так и в выделенных серверах. Доступные карты: NVIDIA® A100⁠, A100⁠ c NVLink, Tesla T4, A5000, A2000, GTX1080 и другие. Плюсы облачного сервера с GPU: ▫️Аренда от 52 рублей в час. ▫️Доступны NVIDIA® A100⁠ c NVLink для обучения, тюнинга и инференса больших языковых моделей. ▫️Менее минуты на создание сервера, быстрая настройка и изменение конфигурации в панели my.selectel.ru. Преимущества выделенного сервера с GPU: ▫️ Вы можете распоряжаться всеми ресурсами и изолировать свой проект от других клиентов. ▫️Запуск в течение нескольких минут после заказа. ▫️В цену включен безлимитный интернет-трафик — 1 Гбит/с. ▫️На сайте можно выбрать одну из десятка готовых конфигураций для любого вашего проекта. Собрать свой сервер: https://slc.tl/s817e Реклама ООО «Селектел» erid 2VtzqwAyUbK

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

false | true

Если после её выполнения сделать: echo $?, то получим статус выхода 0. То есть у нас есть статус завершения именно команды true. НО теперь узнать с каким кодом завершилась первая команда false? А вот так, модифицируем команду:

false|true ; ( exit ${PIPESTATUS[0]} )

В этом случае будет получен код завершения 1, который справедлив для команды false. Как ты можешь заметить, если в PIPESTATUS изменить [0] на [1], мы снова получим статус завершения 0 (то есть для true).

PIPESTATUS - это специальный массив переменных в оболочке Bash, который содержит статус завершения каждой команды в цепочке команд, выполняемой через конвейер (pipeline). Когда в вашем скрипте используется конструкция конвейера с несколькими командами, PIPESTATUS сохраняет статус завершения каждой из этих команд.

Аналогично можно манипулировать любой частью пайпа и получать нужные тебе статусы.

command1 | command2 | command3
echo "${PIPESTATUS[0]}"
echo "${PIPESTATUS[1]}"
echo "${PIPESTATUS[2]}"

Есть еще много велосипедов для реализации желаемого, но этот коробочный самый распространенный и понятный. Изучай! Больше про коды завершения, можешь найти в этом посте. tags: #bash — 💩 @bashdays

⏰20 февраля, 11:00 Вебинар PT Container Security: какие подходы к безопасности применяют в Docker и Kubernetes? Большинство прогрессивных компаний уже перевели свою инфраструктуру в контейнеры. При этом с их безопасностью не все так просто. По данным Red Hat, 94% IT-специалистов сталкивались хотя бы с одним инцидентом ИБ, связанным с контейнерами: это отсутствие политик контроля конфигураций кластера, несанкционированный запуск сторонних образов, нарушение конфиденциальности секретов. В то же время уязвимости в контейнерах не закрыть классическими СЗИ. На вебинаре расскажем, как в таком случае защитить контейнеры? Вебинар будет интересен: CIO, CISO, архитекторам DevOps, ИБ и AppSec-инженерам, аналитикам SOC, team lead разработки. 👉Регистрация Реклама.

Занятный факап приключился у клиента. На скрине думаю понятно, что произошло. Добро пожаловать в Linux! Эту задачу мне удалось решить за несколько минут, не имея бэкапов я восстановил ему этот удаленный файл. Как раз способом из этого поста. Если кратко, я глянул в логи /var/log/cron, взял рандомную таску которая выполнялась ранее и вбил:

grep -a -C 500 -F 'console import:reports' /dev/sda1

Соответственно console import:reports это часть таски, которая когда-то выполнялась. Команда отработала и нашла мне удаленный cron файл. Копипаста и все рады. Но тут опять же повезло, что данные не перезаписались на диске. В любом случае можно было бы восстановить по хронологии из файла /var/log/cron, но уже с геморроем. Либо грепнуть CRON в syslog и journald. На будущее сделал клиенту алиас:

alias crontab="crontab -i"

Этакая защита от дурака и толстых пальцев. Теперь если перепутать «e» и «r», то оно выругается и запросит подтверждение: crontab: really delete root's crontab? (y/n) Ну и на будущее, не забывай делать бэкапы. Хотя сколько не говори, никто не делает, пока петух не клюнет. Хотя сколько меня не клевал, я все равно зачастую забиваю, видимо уверен, что смогу всё восстановить. Бэкап крона:

@daily crontab -l > $HOME/.crontab

Восстановить:

crontab < $HOME/.crontab

А вообще часто советуют использовать systemd timers вместо cron или systemd-cron, мол они гибче и безопаснее. Ну хз хз, каждый привык выбирать свои игрушки. Всех с пятницей, хороших предстоящих выходных. Увидимся! tags: #bash #linux — 💩 @bashdays

❓ С чего начать работу с компьютерными сетями? 👉 С бесплатного практического урока «Статическая и динамическая маршрутизация» от OTUS. ⏰ Встречаемся 21 февраля в 20:00 мск в рамках курса «Специализация Network Engineer». Доступна рассрочка на обучение! 👉 Регистрируйтесь прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/bNkU/ 💪 На вебинаре вы вместе с опытным экспертом: 1. Разберетесь, зачем нужна маршрутизация и какая она бывает 2. Рассмотрите статическую и динамическую маршрутизацию 3. Реализуете статическую и динамическую маршрутизацию в сети на практике Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Во времена динозавров, мне удалось поработать в профильных компаниях, которые занимаются информационной безопасностью и тестированием инфраструктуры клиентов на проникновение. Однажды обратился клиент, которому злые лоси вынесли инфраструктуру. И когда мы полезли разбирать инцидент, на серверах отсутствовали логи, их просто не было. Их не удалили, их отключили. Тогда еще никто не парился со всякими ELK, да и может таких решений и не существовало вовсе. В общем тут мои глаза и раскрылись, а зачем отключают логи? Правильно, чтобы что-то скрыть. Вектор атаки простой - заимел рута, отключил логи, зачистил то что было и делай свои грязные делишки. И мне стало интересно, а как это провернуть? А если появился интерес, надо тыкать палкой. Сейчас будем решать эту задачу. Как именно, понятия не имею. Будем экспериментировать. Отключаем логирование Цель - папка var/log всегда должна быть пустая и чтобы Linux машина не встала раком. Дополнительно обуздаем journald и history от bash. Первое, что я проверил, удалил все и запретил вообще любую запись в var/log через chmod 000, но после перезагрузки сервера, всё вернулось на свои места. Права на папку стали 755. Однако… Теперь попробуем установить на папку специальный атрибут:

sudo chattr +i /var/log

Перезагружаемся. Хе! Сработало. В папке пустота! На этом можно двигать задачу в done. После установки этого атрибута, у тебя начнет сыпать ошибками apt, но пакеты оно будет ставить, так что имей это ввиду. Это фиксится добавлением строчки Dir::Log "/путь"; в apt.conf.d. НО, не все так просто. Если ввести:

jorunalctl -f

Мы снова видим логи. Но теперь уже на экране. А раз они на экране, значит они где-то лежат и на диске. Давай искать. Зачищаем этот системный журнал:

sudo journalctl --rotate && sudo journalctl --vacuum-time=1s

Ага, на экране видим путь, то что оно зачистило, это /run/log/journal/. Зачистка это хорошо, но логи все равно будут писаться. Надо отключить эту шляпу на глобальном уровне. Открываем файл /etc/systemd/journald.conf и добавляем:

Storage=none

Перезагружаем службу и удаляем остатки:

sudo systemctl restart systemd-journald
rm -R /run/log/journal/*

Теперь если ввести:

jorunalctl -f

Получим такое сообщение: No journal files were found. Прекрасно! Так, если в системе установлен rsyslog или подобное, то дизейблим и его:

systemctl stop rsyslog
systemctl disable rsyslog

Основное сделали. Осталось логирование в .bash_history. Зачищаем и накидываем атрибут на запрет записи:

cat /dev/null > ~/.bash_history
sudo chattr +i ~/.bash_history
history -c && history -w``

Либо добавляем в .bashrc строчку: HISTSIZE=0, с ней будет нативнее и без костылей с атрибутом. Делаем финальную перезагрузку. Ну вот и всё, задача выполнена. Система зачищена от логирования. По любому я что-то упустил, поэтому жду с нетерпением твои комментарии. Вообще все эти способы очень грубые и топорные. Было бы намного изящнее сделать решение, которое удаляет из логов только то, что нужно удалить. Логирование работает в штатном режиме, но критичные данные в логи не попадают. Всех обнимаю, хорошего дня! Прошу отметить, что предоставленная здесь информация предназначена исключительно для образовательных и информационных целей. Я не призываю и не одобряю незаконные действия, и использование этой информации для незаконных целей запрещено. Читатели должны соблюдать законы своей страны и использовать свои навыки с уважением к этическим нормам и законам. tags: #bash #linux — 💩 @bashdays

⚡️Тест по мониторингу архитектуры Ответьте на 15 вопросов и проверьте, насколько вы готовы к обучению на курсе — "Observability: мониторинг, логирование, трейсинг" от Отус. Курс доступен в рассрочку. Научитесь строить эффективные системы мониторинга и логирования. Курс идеально подойдет администраторам Linux, DevOps-инженерам и разработчикам, которые хотят повысить квалификацию и увеличить доход. ➡️ ПРОЙТИ ТЕСТ: https://vk.cc/cuDXZh — Курс подойдет администраторам Linux, DevOps-инженерам и разработчикам, которым нужно настраивать мониторинг, логирование и трейсинг с помощью Prometheus, Grafana, ELK и Tempo. 🤝 Бонусом за успешно пройденный тест, получишь доступ к записям лучших вебинаров курса. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Привет. В прошлом посте про мы с тобой познакомились с $@ и $*. Сегодня разберем остатки этих прекрасных баксовых штуковин.

$1/$2/$3 - позиционные параметры переданные в скрипт $# - количество переданных аргументов $- - текущие флаги оболочки $$ - идентификатор процесса PID $_ - последний аргумент предыдущей команды $IFS - разделение слов во входящих данных $? - код возврата последней выполненной команды $! - PID последнего запущенного в фоновом режиме процесса $0 - имя исполняемого файла

Теперь на примерах Позиционные параметры

echo "Первый аргумент: $1"
echo "Второй аргумент: $2"
echo "Третий аргумент: $3"

./script.sh one two three

Выведет:

Первый аргумент: one
Второй аргумент: two
Третий аргумент: three

Количество переданных аргументов

echo "Количество аргументов: $#"

./script.sh one two three

Выведет:

Количество аргументов: 3

Текущие флаги оболочки

echo "Текущие флаги оболочки: $-"

Выведет:

Текущие флаги оболочки: himBHs

Про эти флаги можешь почитать в этом посте. Идентификатор процесса PID

echo "PID текущей оболочки: $$"

Выведет:

PID текущей оболочки: 362748

Последний аргумент предыдущей команды

echo "Hello BashDays"
echo "Welcome Home"
echo "Последний аргумент предыдущей команды: $_"

Выведет:

Последний аргумент предыдущей команды: Welcome Home

Разделение слов во входящих данных

IFS="," 
read -ra words <<< "hello,bashdays,how,are,you"
for word in "${words[@]}"; do
    echo "Слово: $word"
done

По умолчанию у $IFS это пробел, но можно заменить на что-то другое. Тут указываем, что разделитель у нас будет «запятая». Вывод будет таким:

Слово: hello
Слово: bashdays
Слово: how
Слово: are
Слово: you

Код возврата последней выполненной команды

ls non_existent_file.txt
echo "Код возврата: $?"

Выведется:

ls: cannot access 'non_existent_file.txt': No such file or directory
Код возврата: 2

PID последнего запущенного в фоновом режиме процесса

sleep 10 &
echo "PID последнего запущенного в фоновом режиме: $!"

Выведет:

PID последнего запущенного в фоновом режиме: 362786

Имя исполняемого файла

echo "Имя этого скрипта: $0"

Выведет:

Имя этого скрипта: -bash

А если выполнить из скрипта, то оно покажет его имя. Вроде всё упомянул, если что-то упустил, добавляйте в комментарии. tags: #bash — 💩 @bashdays

Готовы влюбиться в свою карьеру? Регистрируйтесь на бесплатный вебинар «Драмы больше нет: как найти работу без слез и страданий», чтобы освоить мощные стратегии для поиска работы, которая будет радовать вас, как валентинки от рекрутеров! На нашем вебинаре вы узнаете, как: ✅ Грамотно подходить к каждому этапу поиска работы, минуя слезы и страдания ✅ Создать резюме и сопроводительное письмо, которые заставят рекрутера влюбиться с первого взгляда. ✅ Готовиться и проходить собеседования так, чтобы HR ждали вашего звонка с предложением работы больше, чем сладостей к чаю. ✅ Использовать профессиональные сети и социальные медиа, чтобы привлекать внимание работодателей ежедневно, а не только по большим праздникам. 💌 Получайте валентинки от рекрутеров не только 14 февраля, а круглый год!👇🏽 http://careerum.link/CPb7i Erid: LjN8KF7Bg Реклама ИП Солнцев И.Ю. ИНН 773129141416

Привет. Странный факт - всю неделю с нетерпением ждешь выходных, а когда дождался, щелчок пальцами и снова наступил понедельник. А когда отдыхать-то? В рабочие дни разгребаешь рабочую рутину, в выходные разгребаешь домашнюю рутину. Вот такой вот замкнутый круг получается. С другой стороны ты всегда находишься при деле, в потоке. Меньше времени остается на нытье и на самокопание. А это уже большой плюс. Окей, поныли и хватит, летсгоу! Ты тёртый калач и всяко знаешь про специальные переменные со знаком $. Держу пари, знаешь только про базовые и часто используемые, типа $? и $1. Сегодня рассмотрим еще парочку $@ и $*. Эти специальные переменные по сути выполняют одну и туже задачу: выводят список всех аргументов переданных скрипту. Но естественно есть различия в их использовании. Голову не грей, теория всегда душная, сейчас на примерах рассмотрим и всё у тебя в голове сложится как надо. Начнем с $@, накидываем скрипт:

echo "Изучаем \$@"
for arg in $@; do
    echo "Аргумент: $arg"
done

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

./script.sh 1 2 '3 with spaces'

На экран выводится:

Изучаем $@
Аргумент: 1
Аргумент: 2
Аргумент: 3
Аргумент: with
Аргумент: spaces

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

echo "Изучаем \$@ с кавычками"
for arg in "$@"; do
    echo "Аргумент: $arg"
done

В этот раз на экран выведется такое:

Изучаем $@ с кавычками
Аргумент: 1
Аргумент: 2
Аргумент: 3 with spaces

Вот! Тут мы получили уже более ожидаемый результат. Массив: {$1, $2, $3} Теперь про $*

echo "Изучаем \$*"
for arg in $*; do
    echo "Аргументы: $arg"
done

После запуска с такими же аргументами:

Изучаем $*
Аргументы: 1
Аргументы: 2
Аргументы: 3
Аргументы: with
Аргументы: spaces

Получаем то же самое, что и с $@ без кавычек. Шило на мыло. А вот если заключить $* в кавычки:

echo "Изучаем \$*"
for arg in "$*"; do
    echo "Аргументы: $arg"
done

На экране мы получим:

Изучаем $*
Аргументы: 1 2 3 with spaces

Вот и отличие. Оно небольшое, оно практически ненужное. Но в этом и кроются детали. Все аргументы объединились в одну строку, отделенным символом пробела, заданным в IFS (пробел по умолчанию). Если это не знать, то легко можно наступить на грабли. Вот пример как заменить IFS разделитель (пробел на запятую):

echo "Изучаем \$*"
IFC=","
for arg in "$*"; do
    echo "Аргументы: $arg"
done

Вывод будет таким:

Изучаем $*
Аргументы: 1,2,3 with spaces

Как «эффект бабочки», забыл поставить кавычки, сломал в будущем логику. Поставил кавычки, сломал другую логику. Куда не ткни, вечно какие-то костыли. Я конечно сомневаюсь, что ты пользуешься таким высокоуровневым программированием (я не пользуюсь), но порой бывает натыкаешься на чужие скрипты с подобной логикой. И тогда важно не попасть в просак. А что такое просак, хорошо объясняется в фильме «Жмурки». Ладно, не смею тебя больше отвлекать. Увидимся. Хорошего понедельника! tags: #bash #linux — 💩 @bashdays

Вот и до наших краёв донеслась снежная стихия, какая-то «Ольга». Ну хоть не «Арбузова». С названием переменных явно не заморачивались. Ну да ладно, сегодня тоже будет про переменные в Bash. Не все понимают чем отличается определение переменной в Bash c export и без. Сейчас расскажу, чтобы ты больше не сомневался. Есть 2 распространенных способа объявить переменную:

export var=значение
var=значение

Что тут не так? А тут всё так. Только в первом случае я использую export, чтобы сделать переменную доступной для подпроцессов. То есть, переменная заданная через export будет доступна для любого процесса, который будет запущен в рамках процесса оболочки. А если задать переменную БЕЗ export, то переменная будет доступна только в самой оболочке и недоступна для других процессов. Скучная теория, давай на практике:

var1="Hello Bashdays"
echo $var1

Hello Bashdays

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

export var1
var2="Bye, Bye"
bash
echo $var1

Hello Bashdays

echo $var2

1. Экспортируем var1 3. Объявляем вторую переменную var2 4. Запускаем bash в bash (подпроцесс) 5. Получаем значение переменной var1 6. Получаем значение переменной var2 В пятом пункте переменная var1 вывелась на экран даже после того, как я запустил еще одну оболочку bash внутри оболочки bash. Переменная стала доступна для подпроцессов. А вот var2 которую я объявил во втором пункте, куда-то делась. На самом деле она никуда не делась, просто подпроцесс её не видит. Стоит мне сейчас сделать так:

exit
echo $var2

Bye, Bye

Я получаю значение переменной var2. Если уж совсем грубо говоря, export делает переменную глобальной на уровне подпроцессов. Ну и частые ошибки, когда пытаешься экспортировать массив:

export Array=("Hello" "Bashdays")

С виду все в порядке и вроде логично, ошибок нет. НО в подпроцессах если попытаться вывести содержимое этого массива, ты получишь пустоту. И люди на это убивают несколько часов, чтобы понять в чем причина.

А причина простая, просто нужно знать — в Bash не существует прямой поддержки экспортирования массивов.

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

Array=("Hello" "BashDays")
export ArrayString="$(printf "%s|" "${Array[@]}")"
IFS='|' read -ra Array <<< "$ArrayString"
echo "${Array[@]}"

Значок собаки = все элементы массива, его можно справедливо заменить на 1, 2, 3 и т.п. А printf используются для форматирования массива в строку, разделяя элементы символом «|». Теперь массив экспортирован и будет доступен в подпроцессах. Вообще холиваров на тему экспортирования переменных очень много, каждый топит за своё, но тут уже хозяин барин. Как говорится под каждую задачу своё решение, где-то необходим export, где-то он и не нужен. Ладно чо, хороших тебе предстоящих выходных и береги себя! tags: #linux #bash — 💩 @bashdays

☝️ Бесплатный практический урок для начинающих сетевых инженеров 👉 Приглашаем на занятие «IP форвардинг в L2 и L3 сегментах» от OTUS. ⏰ Встречаемся 13 февраля в 20:00 мск в рамках курса «Специализация Network Engineer». Доступна рассрочка на обучение! 👉 Регистрируйтесь прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/yumUU/ 💪 На вебинаре вы вместе с опытным экспертом: 1. Разберетесь, как происходит процесс передачи IP пакетов в L2 сегментах 2. Узнаете, как происходит процесс передачи IP пакетов в L3 сегментах 3. Реализуете L2 и L3 сегменты сети на практике Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Привет. Немного терминальной развлекухи :

curl ascii.live/parrot  
curl ascii.live/forrest  
curl ascii.live/can-you-hear-me
curl parrot.live

А тут и тут можешь посмотреть исходники этих проектов. Там еще много подобных curl запросов можно понаделать с котиками, пончиками, бэтменами. А еще можно поставить себе на сервер и устраивать консольные вечеринки. tags: #linux — 💩 @bashdays

Привет. Разгребал тут мамонтовский сервер и нашел исходник с таким артом. Думаешь это всего лишь картинка из архивов старого фидошника? Нифига, это Acme EyeDrops. Visual Programming in Perl. В арте зашит вполне рабочий perl код. Если сохранить эту картинку в файл и затем выполнить его через интерпретатор, ты получишь секретное сообщение.

perl ./pokazisiski.pl

Сам код этого арта, сгенерирован с помощью модуля Acme::EyeDrops. Кстати на странице модуля много примеров с такими картинками (верблюды, морды, заборы, снежинки), каждая выполняет какое-то своё действие + есть примеры генераторов. А вот эта команда, превратит файл обратно в исходник. То есть выведет исходный код вместо того, чтобы его выполнить.

perl -MO=Deparse ./pokazisiski.pl

Опять же не знаю, что ты будешь делать с этой информацией. Говорят что perl давно мёртв, но в современных скриптах и решениях люди любят его применять. ХЗ почему, наверное потому что perl есть везде. Хотя сейчас глянул, последний релиз был 2024-01-20, версия 5.39.7 (devel), капец, оно живое. Первое и последнее, что я делал на perl, это был вывод «Hello World», на этом моё знакомство с ним закончилось. Даже на СИ порог вхождения мне легче показался, хотя по СИ у меня была книга, а по perl только какие-то огрызки из фидонета. Ладно. Побежали дальше мир спасать от криворучек. Увидимся! А ты применяешь perl в современном мире? Если да, поделись пожалуйста в комментариях, как и где. Очень интересно. tags: #linux — 💩 @bashdays