Боюсь что все это полная хрень. Сам долго так думал, а потом перешел на полностью электронные конспекты. Ну и если честно - значение конспектов преувеличено. Как там говорил Сократ?
Да даже копируя простой tail --lines=100 из ответа стаковерфлоу
Вы не правы, совсем. Языки прячут os-specific штуки за абстракциями. Добится неработоспособности какого-то кода на одной из платформ - очень и очень сложно. Нужно прямо хорошенько постаратся.
.. нет, не можете. То, что вы хотите, называется не библиотека, а целое консольное приложение. Что бы у нее была точка входа, парсер аргументов, вывод exit code, stdout и stderr. Это в разы дольше и сложнее, чем просто библиотека, которую можно использовать только как зависимость к другому проекту и никак иначе.
Не могу, к сожалению. Этот конкретный пример - вообще не место для скриптового языка. А другого примера не знаю, но уверен, что у скриптовых языков есть применение. И именно о таких местах надо было говорить изначально)
Я поэтому и уточнил, что мы взяли этот кейс для примера.
Речь вообще может идти не об обновлении. И даже если говорить об обновлении, то аргумент "подавляющее большинство" не валиден, ибо если есть хоть одна софтинка, которой нужно что-то кроме нее самой, то с этим подходом в корне уже что-то не так, раз он не универсален.
Имел в виду то, что для самих скриптов может быть нужно что-то еще. Такие же доп. зависимости, какие могут быть нужны и в примере выше.
Понятно, что простенькие баш скрипты скорее всего будут работать везде. Но даже у этого нет никаких гарантий! Если у ls на макоси или у ls на ubuntu 10 какого-то одного флажка нет, потому что там ls кастомный или старой версии, то даже с "популярными" gnu tools ваш скрипт завалится.
Условная котлин библиотека не компилируется в баш и, обьективно, никогда не будет. А использовать такую библиотеку как executable вы не сможете, так как это библиотека, а не executable :/
Я вел к тому, что решения типа докер компоуза подходят сюда намного лучше, чем любая полу-ручная автоматизация.
Принимаем решение исходя из цены и выгоды обеих решений.
Обьективно, уязвимости находятся довольно редко.
Я просто хотел узнать, что нужно впитать до того, как приступить к изучению уже языков, потому что языки, как по мне, это уже вторая ступень к становлению джуном.
И да, вот, кстати, карта, по которой я, незнающий некоторых элементарных вещей в этой области, должен стать геймразработчиком.
Ну мы же для примера взяли базу и вообще процесс обновления) Явно не может быть такого, что всегда обойдется без зависимостей, это нонсенс.
Для баша? Или для типичных (опять же, типичных в моем понимании) скриптов на нем? Первое - это понятно, а второе - отписал выше)
Нет. Вы же спросили про "метод", я про него и ответил. Фронт и бэк априори не могут быть на одном фреймворке, но легко могут использовать библиотеку, написанную на одном языке.
Ну не прям руками. Но и не автоматически. Опять же: есть у вас 50 девов и в придачу еще 6-8 стейдж/прод енвов. На каждом будете вручную запускать скрипт, даже если допустить, что он универсально выполнится на linux/macos/docker разработчиков и условный ubuntu/docker стейджов? А если через день найдется бажок и нужно будет откатить? Опять все руками?
Это, все таки, разные вещи. Если вас в команде 3 человека и у вас только стейдж и прод - ок, это терпимо. Но с любым более-менее большим проектом это совсем не работает.
Патч и даже минорная - нет, не требует, иначе вам стоит сменить фреймворк. Если мажорную - конечно, но мажорные версии любых больших продуктов выходят не чаще раза в год. Там подготовка, согласование и костыли при апдейте - вполне нормальны.
Вообще я не понимаю, как это связанно с тем, о чем мы разговариваем. Но все проходит через пулл реквесты, встроенные автоматические секьюрити чеки и проверку лицензий. Если имеется в виду ручной аудит, то это либо просто еб*нутые конторы, которым некуда потратить сотни тысяч на разработку собственных решений (вместо тех, которые предполагаемо не пройдут аудит), либо очень большие конторы, которым это даже выгодно.
Спасибо) Но это всего-лишь пример.
наверное потому что linux и macos это разные ОС, но при этом обе системы посикс-совместимые.
Давайте так. Все мои попытки вам что-то пояснить приводят к тому, что вы говорите "ну это всего лишь пример, это всего лишь предположение".
Давай если будешь еще что-то писать в этот и так уже длинный тред, ты будешь приводить конкретные примеры, с конкретными несовместимостями. Потому что это реально надоедает каждый раз опровергать ваши предположения. Они ж так никогда не закончатся, и при этом еще ни одно не подтвердилось.
Чем плохи конфигфайлы? При этом их даже не обязательно менять, можно просто оверрайдить значения через переменные окружения (скорее всего об этой фиче в java вы не знаете).
В том-то и дело, что для CLI оболочки это не нужно совершенно. Нужна стабильность, универсальность, хорошая интеграция в первую очередь с ОС, а не со сторонней разработкой.
Асинхронность можно сделать в баш. Параллельность тоже. Экосистема у баш также присутствует. Синтаксис - ну тут у вас просто личная неприязнь к баш. Как я уже писал, в мониторинге, я частенько пользуюсь питоном, если надо сделать кастомный граббер данных.
Но опять таки - в качестве shell, в качестве языка для администрирования и автоматизации простой рутины, в качестве клея для миллионов CLI утилит, внутри различных инструментов по CI/CD и так далее - bash/ksh/zsh - это идеальный инструмент в *nix, и он настолько комфортный, что пока что нет даже смысла с нуля писать что-то другое. Хотите развития - zsh это то, куда сейчас идет линукс шелл официально. Возможно лет через 10 он будет дефолтной оболочкой во многих дистрибутивах, ибо обратная совместимость у него полная.
В Windows так сложилось, что рулит не сообщество, а MS, и там рулит powershell, который значительно сложнее по синтаксису, поэтому он многим не нравится. Но да, он мощный, с кучей интеграции из коробки. Вот только простые вещи на нем делать сложно, поэтому часто параллельно с ним юзается либо совсем убитый старый cmd либо ставят что-то рядом, типа bash.
Но смотреть какой другой "мощный" язык заменит именно баш и именно везде - в ближайшие лет 10 такого не будет. Хотите - сохраните букмарк на эту тему, надеюсь тостер через 10 лет будет жить, отпишетесь кто оказался прав.
P.S. Я со своей стороны закругляюсь. Тред слишком затянулся, хоть я и старался быть конструктивным и держаться в рамках топикстартера.