Проект PaSh, развивающий инструменты для параллельного выполнения shell-скриптов, объявил о переходе под покровительство организации Linux Foundation, которая предоставит инфраструктуру и сервисы, необходимые для продолжения разработки. Код проекта распространяется под лицензией MIT и включает компоненты на языках Python, Shell, C и...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55877
Может у них и транслятор ./configure -> CMake есть?
В новости про мягкое, а вы про зелёное.
"Програмирую на Баш" - обретает новій смьісл.
> -parallel из PowerShellЭто вообще не то.
Наоборот.
Это виндонабросчик с одной извилиной, и та пожароопасная -- не кормите лишку, лучше сразу "к модератору".А так-то можно и pdsh со товарищи вспомнить, что я было и подумал при виде заголовка...
PS: посмотрел на осеннее обострение этого несчастного и вычистил его всего нахрен, не читая сообщения вообще. Такое вот наказание за полную невменяемость.
До повершела Башу деградировать вечность, так что никогда не дойдет.
Если речь идёт о ForEach -Parallel из 5.1, то это как раз то самое.
Итератор обходит коллекцию. Если встречается конвейерная обработка объекта коллекции внутри скриптблока, то эта часть отработает параллельно "автомагически". Если явно показано, где нужно параллелить, то тоже получится. Это очень похоже на тот разбор, который делает PaSh... вот только это доступно только как часть System Center SMA через модуль PSWorkflow и не очень то надо, когда у тебя в языке паралеллизм и так из коробки доступен как свой через Jobs так и средствами .net внутри которого оно выполняется. Ничего же не мешает написать свои кастомные классы и работать с потоками по вкусу изнутри лругого дотнетовского языка, если прямо сильно хочется.Если речь о ForEach-Object -Parallel из 7.0, то нет это не оно.
Там произойдет перенос всей обработки скриптблока в разные runspaces, которые распределятся по заданному количеству в ThrottleLimit количеству сценариев в параллельных потоках. Это, по-сути, синтаксический сахар над jobs, поэтому в случае с выполнением в изначально параллельных частях PS или в других runspaces, например, через PSRemoting, нужно не хило будет так заморочиться с ручной сериализацией и десериализацией аргументов скриптблока, если они есть, опять же. Ну и оверхед там будет колоссальный на порождение пачки runspaces. Это не для распараллеливания инструкций по-максимуму, это когда нужно выполнить длинный не имеющий промежуточных состояний долгий скрипт прямо из конвейера.
> Если речь о ForEach-Object -Parallel из 7.0, то нет это не оно.Я именно об этом и говорил, что не оно.
> Это не для распараллеливания инструкций по-максимуму, это когда нужно выполнить длинный не имеющий промежуточных состояний долгий скрипт прямо из конвейера.
Как я понимаю, это было запилено, чтобы одновременно опрашивать (или что-то делать) управляемые скриптом PS сервера, а не перебирать их по очереди.
да, неплохо наворотил майкрософт. абстракция на абстракции сидит
и абстракцией погоняет. и все это в нескольких версиях.пожалуй, мое решение не изучать и не использовать повершелл было правильным.
иначе так бы и блуждал во всем этом.впрочем, наверняка найдутся люди, которым это понравится.
не буду их осуждать, не буду считать их лохами и техноздаротами.
Вообще-то - глубоко ошибочным.
1. Ни в одной серьезной конторе не используется только линакс-среда. Чистая винда бывает, а чистый линакс - не дорос.
2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше чем баш на Винде.
3. Повершелл - сложней башв, но зато - предоставляет несколько более широкие возможности.В связи с вышесказанным в любой конторе, доже использующей комбинированную среду выбор средства автоматизации (скрипты) однозначен. И это не баш😁
Вот такая смешная ситуация - линаксоид без знания повершелла не нужен...
> Вообще-то - глубоко ошибочным.хорошо. я проиграл, а техно-этисамые выиграли. рад за них. если они хотят тратить свои нейроны на чертоплешь - пусть тратят, видимо что-то серьезное они получают взамен (знать бы еще что).
> 1. Ни в одной серьезной конторе
открою небольшую коммерческую тайну - В ЭТОЙ СТРАНЕ НЕТ "СЕРЬЕЗНЫХ КОНТОР".
при ближайшем рассмотрении каждая претендующая на серьезность контора
распадается на конгломерат гнезд из сношающихся жаб и гадюк, где кто во что горазд.
"единая техническая политика" - невыполнимая мечта недалеких CIO.> 2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше
что значит "выглядит" ?
> 3. Повершелл - сложней башв, но зато - предоставляет несколько более широкие
> возможности.к "баш" (на самом деле /bin/sh) прилагаются grep, sed, awk и perl (но последний ожирел и на крайний случай). возможности последних надеюсь объяснять не надо.
> В связи с вышесказанным в любой конторе,
см п 1
> Вот такая смешная ситуация - линаксоид без знания повершелла не нужен...
думаю кто-то из нас заврался. и это не я.
>> 2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше
> что значит "выглядит" ?Ну имеется ввиду интеграция со всеми остальными системными вещами.
>> 3. Повершелл - сложней башв, но зато - предоставляет несколько более широкие
>> возможности.
> к "баш" (на самом деле /bin/sh) прилагаются grep, sed, awk и perl
> (но последний ожирел и на крайний случай). возможности последних надеюсь объяснять
> не надо.Да-да-да. Для cmd.exe - они тоже есть, но толку-то? :)
> 1. Ни в одной серьезной конторе не используется только линакс-среда. Чистая винда бывает, а чистый линакс - не дорос.Это вранье, на самом деле все наоборот, на что мягко намекает линукс в ажуре, порты сугубо виндузятных программ на линукс, wsl(который такой же кривой как и сама винда).
> 2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше чем баш на Винде.Что лишь подтверждает пункт 1. Но очень забавно что в укор линуксу вы приводите работу баша (который прекрасно работает например на макокосе) на винде, а не техподдержке мелкософта (у которого 20 лет нормальной консоли то не было, а то что было и появилось до сих пор страдают нереальной кривизной реализации вроде недоюникода).
> 3. Повершелл - сложней башв, но зато - предоставляет несколько более широкие возможности.Ага, баш не умеет например сортировать, но только потому что архитектурно построен грамотней повершелла и ему это не нужно (т.к. есть sort из gnu utils) и это за 17 лет до повершелла (а если учитывать что архитектурно баш мало что добавляет sh то и вовсе за 29 лет).
Но и bash уже устарел (на что намекает сабж) и больше используется по причине "есть везде от микроконтроллеров до суперкомпьютеров" и с моей т.зр. очень забавно что гораздо более молодой софт (который к тому же не заботился об обратной совместимости в отличии от bash) сливает такому старцу.
Ой, недавно же обсуждали - в линаксе отсутствует аналог MSAD. Увы и их - без этого корпоративной среды не бывает. И много чего еще...Линакс используется... На некритичных направлениях в качестве вспомогательной ОС. Например - веб-сервер. Ну или ОС для ноды виртуализации - в виде VmWare или Citrix Hypervisor :)
> баша (который прекрасно работает например на макокосе)
И что с этого? Вы сюда заглядывали https://github.com/PowerShell/PowerShell/releases/? Очевидно что нет иначе бы знали что PowerShell тоже прекрасно работает на макоси. Которая к слову - ну ни разу не корпоративная система. Кстати больше всего меня поразила официальная сборка PowerShell под Alpine Linux... Про rhel/debian/ubuntu - понятно что есть.
> баш не умеет например сортировать, но только потому что ему это не нужно
Вы правы - ему это не нужно. А насчет "грамотней" - не согласен, он другой и построен на безнадежно устаревших подходах времен COBOL, PL/1 и прочего антикравиата. На их фоне он смотриться передовым решением - факт. :)
>Линакс используется... На некритичных направлениях в качестве вспомогательной ОС. Например - веб-сервер.Как там в вашем 1999-м?
что-то все больше в больших конторах (ну не берем рога-и-копыта из 10 человек) используют именно AD,
а не свистоподелки в виде OpenLDAP.
Давайте не будем сравнивать AD и OpenLDAP. Это все равно что сравнивать ну например postfix и скажем OpenXchange
> Линакс используется... На некритичных направлениях в качестве вспомогательной ОС. Например - веб-сервер.А, вот оно что.
Ну окей, мы поняли, в какого уровня серьёзных конторах вы работали. =)
Эх, молодежь - "линакс" используется на подавляюще большем количестве устройств. А юникс-подобные системы оставляют лишь небольшой, но уютный, уголок ОС Windows для непрофессиональных пользователей. Ну и Майкрософт сейчас делает очень много для линукса, пора войн ОС закончилась, все заняли свои ниши и довольны этим.
Мой дорогой, но слабообразованный друг - мой первый юникс был на СМ1420...И таки да - я прекрасно знаю что линакс используется в куче бытовухи - типа роутеры-мыльница, мабилки (хотя там важнее жаба - линакс так... как среда для запуска жабки). Я в курсе что например в Cisco ASA в качестве запускалки - тот же линакс. Правда из него выкинуто все, в первую очередь - сетевой стек и написан свой, с нуля. Я в курсе что аналогичным образом он используется в некоторых воспомогательных модулях той же Cisco и других производителях серьезного сетевого железа. Нет-нет, в джуниперах и нетапах - в основе фряха, тоже по факту - в качестве зускалки. :)
И я прекрано в курсе результатов построить корпоративную среду на базе линакса - да-да, импортозамещение, оно самое... :) Кратко - ни у кого не получилось пока что... :)
Мой высокообразованный, но не далекий друг, наш мир - это капитализм. Просто посмотри сколько платят разработчикам под линукс, а это, как правило, хайлоад, обычно это докеры, контейнеры, всякие там кубернетсы и пр. И все это на линукс. Ни один сервис в мультирегиональных масштабах, 24/7, делать на Windows не будут - денег жалко. ОС, которая не поддерживает иноды не может быть профессиональной, по определению. На простоях при обновлении разорятся. Ну а твой пример про сотню, другую хомячков, в корпоративных целях - детский лепет.
> Ни один сервис в мультирегиональных масштабах, 24/7, делать на Windows не будутТолько на нем и делают. Внезапно, да?
Только не 6адо тут про гугль и прочие штучные поделия... Я говорю о полноценных, тиражируемых решениях.
Вы слышали что-нибудь, скажем, про perl?
Легендарный односторонние на перл в повершеле написать не получится - факт. Имхо это не недостаток ни разу 😂
>2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше чем баш на Винде.Лучше Баша выглядит наличием телеметрии?
>>2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше чем баш на Винде.
> Лучше Баша выглядит наличием телеметрии?Итак - исходники PowerShell находяться здесь - https://github.com/PowerShell/PowerShell
У тебя есть возможность указать, где там телеметрия или прослыть 314...м :) Ну и если обнаружишь - может сразу патчик подготовить для ее удаления - благо MIT License это позволяет.
>В связи с вышесказанным в любой конторе, доже использующей комбинированную среду выбор средства автоматизации (скрипты) однозначен. И это не баш😁В здравом уме ни то ни то никто не станет использовать.
Уже питон в крайнем случае.
А какую версию пихона по-вашему надо использовать-то?Вот есть одна контора - использовала пихон. Второй разумеется. Долго использовала... Сейчас переводят все на PowerShell - это оказалось проще и дешевле чем перейти на 3й пихон. А то выйдет 4й - и понеслось все по новой...
По моему лучше никакую.А так то вопрос странный, очевидно 3+
Пихон это нечто уникальное по несовместимости между своими же версиями. Поскольку его очень любит красношапка, а единственный корпоративный дистрибутив линакса делают они, я много раз сталкивался с засадами совместимости между версиями пихона. Нет, просто взять и поставить последнюю версию - нельзя.Кстати да - GIL это тоже весело, прям как во времена MacOS Classic попал...
Вообщем не пихон - точно.
Лисп решение реальное.
Guix есть от гну, есть ракет схема(rash shell) есть всякие kitty.Старое как это самое Айти, изобретено десятилетия назад. Ничего ненужно переизобретать.
Lisp давно умер. REXX куда более живой ибо сделан професионалами.
> Lisp давно умер.Да вы издеваетесь, мейнстрим только только до некоторых фич лиспа стал доходить.
>> Lisp давно умер.
> Да вы издеваетесь, мейнстрим только только до некоторых фич лиспа стал доходить.Ой, вот по мне так лисп - это диагноз. Язык конечно был прикольный, новаторский... для своего времени. Но простите - что это тупик имхо очевидно после 60+ лет его прозябания на задворках ИТ...
Его ровесники - FORTRAN и COBOL имеют гораздо более широкое применения, даже сейчас.
А так... "чисто академических" языков типа лиспа - было вагон и маленькая тележка. Мне например до сих пор очень нравится FORTH, но я же не говорю что это - идеальный язык с богатыми переспективами :)
>Но простите - что это тупик имхо очевидно после 60+ лет его прозябания на задворках ИТ...christian schaffmeister https://github.com/drmeister, uses a custom lisp impl to compute protein/polymers spatial configurations
some lab used lisp to make a custom dsl for quantum computing
A commercial research laboratory (HRL Laboratories) and two well-funded startups (Rigetti Computing and DWave Systems) all use Common Lisp extensively.https://coalton-lang.github.io/20211010-introducing-coalton/
There is also some Clojure in the Boeing 737 MAX
NuBank is a South American bank that’s rapidly growing and uses Clojure for most of their stack afaik. You can find a lot of Clojure job postings on their website for jobs in South America and Berlin.
| ITA Software is the once independent company that developed the system for air tickets
| search and pricing. Now it forms part of Google’s travel industry department. In most cases,
|the company develops its software using Allegro Common Lisp.
That is not true, no Allegro at all. We use SBCL (in fact dougk is one of the main SBCL maintainers).
Circle CI is one of the largest and, probably, most well-known platforms for CI/CD with millions of builds every month and other impressive statistics that can be found on their website. The major part is written in Clojure; ClosureScript is used for frontend development. In general, developers are so fond of Clojure that in 2021 it ranked second among the most loved technologies of Stack Overflow users according to their annual survey.
Список огромен на самом деле. Но фейсбука видимо нет, лол.
> Ой, вот по мне так лисп - это диагноз. Язык конечно был
> прикольный, новаторский... для своего времени. Но простите - что это тупик
> имхо очевидно после 60+ лет его прозябания на задворках ИТ...
PS используют на венде, а питон на линуксе. У обоих проблемы с кроссплатформенностью, кстати.PowerShell выгоден, если ты умеешь программировать на нормальном языке, типа С/С++/C#. Тебе не нужно писать биндинги, потому что PS умеет автоматически маршалиться к либам если они доступны через CLR и COM. P/Invoke тоже есть, если надо.
В питоне тебе нужно либо писать биндинги на всё, либо pip скачать бесплатно без смс васян-поделие в надежде, что кто-то написал и тебе его код подойдет.
Если у тебя SOAP и/или работа с XML, то питон проще на сразу на помойку выкинуть. Вообще оно не умеет нормально сериализовать свой объекты во что-то кроме своего костыля (pickle), лучшее на что можно надеяться - словари в JSON.
У PS же есть другие сложности, например удачи тебе там со строками и потоковой обработкой текста. Там не только язык ООП-шный, там терминал и вся среда... Ну короче у тебя объекты и коллекции в конвейере, а не строки в stdout/stdin. У PS еще и всё жутко многословно. И её собственные классы... там скриптовый код компилируется в CIL, а потом он оседает в кеше и на него запускается JIT. Всё это круто, но нужно учитывать логику работы ввода вывода в этой ситуации (код выполняется не в терминале, а в CLR).
Я на обоих писать/читать умею, но если мне нужно выбрать, то почти всегда выберу PS, потому что на питоне больше рутины и обвязочного кода. Разница примерно в 2.5 раза по количеству строк (за счет ООП-абстракций, который в CLR есть и не надо изобретать велосипед и из-за биндингов).
> В здравом уме ни то ни то никто не станет использовать.
Хотя зачем я тебе всё это пишу... ты скорее всего теоретик оторванный от реальности, раз такое пишешь.
>Ну короче у тебя объекты и коллекции в конвейере, а не строки в stdout/stdinТак и должно быть. Так и правильно.
> Ни в одной серьезной конторе не используется только линакс-среда. Чистая винда бывает, а чистый линакс - не дорос.Виндоадмины порядочно дешевле и более распространены. Вот те квест: попробуй нормального опса найти в Норильске, Томске, Владивостоке. Почему, ты думаешь, интеграторы на самолёте аж из Москвы/Петербурга отправляют в эти еб**ня специалистов? Да потому что там их -- хрен найдёшь.
Всё это, безусловно, серьёзные компании. Они добывают нефть, они строят вертолёты, они создают тысячи рабочих мест. И им не упёрся айтишный рокет-сайенс ни на толику. Им достаточно винды. Потому что у винды есть свои плюсы. Самые важные из них -- это AD, Outlook и MS Office. Они являются стандартом де факто, и их хватает для покрытия 99% потребностей корпоративного сегмента.
Однако же, если мы говорим про серьёзные айтишные конторы, то к тебе есть вопросы.
> 1. Ни в одной серьезной конторе не используется только линакс-среда. Чистая винда бывает, а чистый линакс - не дорос.
Вообще говоря, я видел разные конторы, и в некоторых (весьма немаленьких) конторах вместо винды прекрасно юзаются MacOS+Linux. Суть тут в том, что без AD в современном мире жить очень даже можно (OIDC SSO очень даже неплох), а Outlook/Office прекрасно живут и без винды.
> 2. Повершелл есть для линакса. И на нем он выглядит гораздо лучше чем баш на Винде.
Лучше/хуже -- понятия субъективные, и следуют как правило из неправильной постановки вопроса. Правильная постановка вопроса: для каких задач?
> 3. Повершелл - сложней башв, но зато - предоставляет несколько более широкие возможности.
Так себе аргумент. Вот языки семейства Lisp -- это самые мощные и выразительные языки по своей природе. Но где они сейчас? Языки семейства ML -- не только выразительны, но ещё и весьма быстры. Но что ж они не распространены повсеместно? Павершелл сложней баша, но больше всего может -- окей, допустим. И что?
> В связи с вышесказанным в любой конторе, доже использующей комбинированную среду выбор средства автоматизации (скрипты) однозначен. И это не баш
Я тебе более того скажу. Это и не PowerShell. =)
> Вот такая смешная ситуация - линаксоид без знания повершелла не нужен...
В вашей конторе -- может быть, почему ж не верить. Но не обобщайте это на рынок. Это будет шибко ошибочно.
>Потому что у винды есть свои плюсы. Самые важные из них -- это AD, Outlook и MS Office.Страшно спросить. Если это по вашему плюсы то что-же там сейчас недостатки?
>Они являются стандартом де факто, и их хватает для покрытия 99% потребностей корпоративного сегмента.
Жуть и мрак.
>Всё это, безусловно, серьёзные компании. Они добывают нефть, они строят вертолёты
Очень сурьёзно, настолько что бекдоры ANB их не волнуют.
>>Потому что у винды есть свои плюсы. Самые важные из них -- это AD, Outlook и MS Office.
> Страшно спросить. Если это по вашему плюсы то что-же там сейчас недостатки?Нашёл, где спросить. На опеннете. Тут каждый первый тебе ведро недостатков отгрузит. Хочешь -- отгрузи сам. С вероятностью 95% я подпишусь под каждым словом. А мне лень. =)
>>Они являются стандартом де факто, и их хватает для покрытия 99% потребностей корпоративного сегмента.
> Жуть и мрак.Ага.
>>Всё это, безусловно, серьёзные компании. Они добывают нефть, они строят вертолёты
> Очень сурьёзно, настолько что бекдоры ANB их не волнуют.А шпионаж не так сложен, как его голливуд малюет.
Он сложен не в плане супер хакеров, а в плане комплексных мер.И дело тут не в шпионаже как таковом. А в получении возможности в один единственный критический момент повлиять на работу того же вертолёта.
Очевидно что ты очень слабо представляешь процессы добычи нефти или создания и производства вертолетов...Например ты в курсе что такое NX или TeamCenter?
Самый большой недостаток винды это wsl, особенно 2й версии. 🤣Товарищ ещё про шарик забыл, без которого в энтерпрайзе никуда
>Код проекта распространяется под лицензией MIT и включает компоненты на языках Python,Годная новость! И лицензия правильная и место питона верное. Порулить скажем портажами - это для питона ок. Пилить синапс - беда. Остался еще в отдельных людях здравый смысл. Отлично!
Если портеж станет вместо тупления по 15 минут делать компиляцию всех программ одновременно, что не завязаны на последовательность при этом, то будет годно. Гентоводы обрадуются. А то все ведь имеют хотя бы 3950x, 5950x или тредриппер на 64 ядра, так что годно.
а я gnu parallel пользовался
чем это лучше?
тем что как использователь parallel::думал ты
Там ручками говоришь, тут JIT. Кроме parallel(1) тоже есть несколько подобных реализаций именно той задачи -- например, Лёша Чеусов (vle) сделал paexec.
> а я gnu parallel пользовался
> чем это лучше?О, пользователь parallel. Очень рад встретиться. У меня с момента первого анонса parallel возник вопрос, на который я хотел бы получить ответ: что может parallel, чего не мог старый добрый xargs?
Я не в целях подъе***ть, мне правда интересно.
Он может жуткий синтаксис, в котором без пол-литры разобраться сложно. Каждый раз, когда вижу хитрую команду parallel, хочется развидеть это навсегда, даже не пытаясь понять, что там написано...А по сути:
1) parallel имеет кучу способов передачи имен файлов для обработки, от передачи через список в командной строке до sql базы. xargs же, чтобы не ломаться на пробельных символах, может разве что читать с stdin с генератора, умеющего завершающие нули типа find -print0, а их мало и это не очень удобно
2) parallel не смешивает вывод параллельно выполняемых задач, xarg все превращает в кашу, а parallel буфферизирует по отдельности и выводит каждый полностью
> Он может жуткий синтаксис, в котором без пол-литры разобраться сложно. Каждый раз,
> когда вижу хитрую команду parallel, хочется развидеть это навсегда, даже не
> пытаясь понять, что там написано...Ну оно так часто бывает, когда смотришь на инструменты следующего поколения. Это не означает, что они хуже. Возможно, их просто слегонца неправильно использовали, и только. Ведь их практики применения относительно молоды.
> А по сути:
> 1) parallel имеет кучу способов передачи имен файлов для обработки, от передачи
> через список в командной строке до sql базы. xargs же, чтобы
> не ломаться на пробельных символах, может разве что читать с stdin
> с генератора, умеющего завершающие нули типа find -print0, а их мало
> и это не очень удобноНашёл, почитал. Узнал про GNU sql. Выглядит кстати весьма интересно.
В общем, я наверное посмотрю, что ещё оно может, спасибо. С xargs это всё тоже возможно, если правильно заранее обработать ввод тем же awk-ом, но это гораздо сложнее. А parallel имеет вон флаг --colsep, что довольно сильно упростит жизнь при парсинге.В общем, спасибо. Заинтересовали.
> 2) parallel не смешивает вывод параллельно выполняемых задач, xarg все превращает в
> кашу, а parallel буфферизирует по отдельности и выводит каждый полностьюНо это отключаемо, надеюсь? А то бывают разные ситуации. Если задача сыплет в лог много, то буферизировать -- это большие накладные расходы.
Жуть и мрак.Шелл скрипт был ошибкой, вот что неплохо бы заменить как устаревшую жуть.
Так не пользуйся, заставляет, что ли, кто-то?Альтернативных шеллов миллион, как sh-родственных, типа zsh, так и кучи других, типа rc, tcl (его можно использовать как шелл), и ещё кучи разных.
Он озвучивает ту точку зрения, что шелл как язык программирования -- это ужас. Ну да, ужас, но не ужас-ужас-ужас.Особенно если понимать его роль связующего между собственно молотящими программами на сях или же наоборот -- "думалками" на более высокоуровневых языках с более богатыми структурами данных.
И особенно если понимать, что шелловый конвейер -- это функциональное программирование в чистом виде. :)
Пока это простой конвейр, то просто ужас.Когда нужно немножко преобразовать или запарсить текст, то ужас-ужас.
Когда нужно входные аргументы обработать, в файловую систему посмотреть, распарсить текст, выполнить не совсем тривиальную логику и стянуть что-то с инета то ужас-ужас-ужас.
Но многие в использовании баша идут ещё дальше.
Вот это богохульное распараллеливание запилили. К каким ошибкам и дырам в безопасности оно приведёт... Зачем натягивать антилопу на глобус?
И главное оно ни разу не кроссплатформенно потому что окружения разные, не везде баш то есть, не везде есть нужные утилиты и не везде они работают одинаково.
> Когда нужно немножко преобразовать или запарсить текст, то ужас-ужас.А в чём проблема с cut/sed/awk?
> Когда нужно входные аргументы обработать, в файловую систему посмотреть, распарсить текст,
> выполнить не совсем тривиальную логику и стянуть что-то с инета то
> ужас-ужас-ужас.У меня пачка скриптов, которые именно это всё и делают. Например, бэкапы делают. Или создают локи, чтобы избежать одновременного конфликтующих команд. Триггерят пайплайны гитлаба или просто вытягивают артефакты через ту же апишечку. Не понимаю, почему это вселяет в вас такой ужас. Оно просто работает, и уже не первый год.
Нет, ужас в меня это не вселяет. Во мне есть ужас но это другой ужас.
Ужас же шелл скриптов существует вне меня в материальной и не материальной реальности.Ужас потому что не переносимо не поддерживаемо не читаемо не отлаживаемо.
> Ужас потому что не переносимо не поддерживаемо не читаемо не отлаживаемо.Не умеешь -- не используй. =)
>Ужас потому что не переносимо не поддерживаемо не читаемо не отлаживаемо.Да ты просто понятия не имееш как на шеле програмировать, потому шо больше однострочников (которые вообще к шелу лиш косвенно отношение имеют) ничего не использовал очевидно.
Я вот умею многое делать исключительно силами /bin/sh, оно отказоустойчиво и быстро, например:
https://forum.motofan.ru/index.php?s=&showtopic=163337&view=...
Не умею так не умею.Как кстати дела с отладкой обстоят у вас? Чем пользуетесь?
> Не умею так не умею.Так мало кто умеет, большынство понятия не имеют о всех возможностях shell: https://www.opennet.ru/docs/RUS/bash_scripting_guide/
> Как кстати дела с отладкой обстоят у вас? Чем пользуетесь?
Отладкой просто через echo $VAR пользуюсь в проблемных местах, хватает как то.
Ну а банальные ошыбки интерпретатор указывает номером строки скрипта.
Интересно.
А как обработка ошибок осуществляется, и чем тестируете?
> Интересно.
> А как обработка ошибок осуществляется, и чем тестируете?Глазами, в терминале.
Иногда лог в файл направляю.
Я тут мимо старой темы проходил.> Как кстати дела с отладкой обстоят у вас? Чем пользуетесь?
echo конечно хорошо, но для более грамотного дебага надо пользоваться set -x всё же. Этот флаг заставляет шелл выводить полный трейс команд и с раскрытыми переменными во время их выполнения.
> Интересно. А как обработка ошибок осуществляется, и чем тестируете?
try/catch на шеллах есть и реализуется посредством команды trap
>Так не пользуйся, заставляет, что ли, кто-то?Даааа. Заставляет. Тут пол GNU Linux на этом щастье нынче написилькана. Всякие системы сборки и прочие вещи от ольтернативно оларённых линуксов.
>Альтернативных шеллов миллион, как sh-родственных, типа zsh, так и кучи других, типа rc, tcl (его можно использовать как шелл), и ещё кучи разных.
Уникс шелл с его утилитами бредавая штука сама по себе.
Да, альтернативы есть.
>Уникс шелл с его утилитами бредавая штука сама по себе.Какое вообще отношение утилиты имеют к шелу????
Полно натива где в коде используются теже утилиты с /bin/...
> Так не пользуйся, заставляет, что ли, кто-то?Дело-то не в этом.
Когда sh появился, его пользователи знали минимум пару-тройку других ЯП. Потому эти люди писали скрипты, когда это уместно. Потом пришли админы, использовали когда уместно -- для автоматизации.
Далее пришла популярность, и появились те кто на bash пишет программы в 20 KLOC и больше ничего не знает и знать не хочет.
Недавний пример:
$ cat xdg-user-dirs.sh
#!/bin/sh
# коммент вырезан
if [ -x /usr/bin/xdg-user-dirs-update ]; then
/usr/bin/xdg-user-dirs-update
fi[guru@localhost ~]$
Утверждается, что исходный текст содержит ошибку -- отсутствие завершающего символа 0x0A. Потому bash обязан очень громко на него ругаться, а не исполнять.
>[оверквотинг удален]
>
> $ cat xdg-user-dirs.sh
> #!/bin/sh
> # коммент вырезан
> if [ -x /usr/bin/xdg-user-dirs-update ]; then
> /usr/bin/xdg-user-dirs-update
> fi[guru@localhost ~]$
>
> Утверждается, что исходный текст содержит ошибку -- отсутствие завершающего символа 0x0A.
> Потому bash обязан очень громко на него ругаться, а не исполнять.А, типа, это люди, когда пишут на Си или Питоне, пишут код лучше, что ли?
Я вот, например, читал код OpenBSD (система без bash по-умолчанию, между прочим), и там глобальная переменная на глобальной переменной.
Твоя проблема не в баше.
>[оверквотинг удален]
>> #!/bin/sh
>> # коммент вырезан
>> if [ -x /usr/bin/xdg-user-dirs-update ]; then
>> /usr/bin/xdg-user-dirs-update
>> fi[guru@localhost ~]$
>>
Вообще-то я сравнивал баш-программистов со знающими несколько языков и способными выбрать уместный инструмент.
> Я вот, например, читал код OpenBSD (система без bash по-умолчанию, между прочим),
> и там глобальная переменная на глобальной переменной.
Это было в исходниках на Smalltalk? Они не знают про паттерн Синглтон?
> Твоя проблема не в баше.
А что у меня за проблема?
Из коробки в линуксе сразу есть Perl и Python. Даже ставить не надо специально.Кто мешает писать скриптоту на них?
Отвечу примером из жизни:Я: Привет! Что делаешь?
Коллега: Пишу скрипт для ...
Я: Прикольно, а на чём?
Коллега: Python3.7
Я: А ты в курсе что твой скрипт должен работать в том числе на Debian7 и Centos6?
Коллега: @ляshell скрипты обладают хорошей кросс платформенностью в linux-unix среде, имеют открытый код, не требуют сторонних библиотек или модулей языка.
В этом плане удобнее всего PHP, у него весь рантайм укладывается в один бинарник, который можно ещё и статически собрать, никаких россыпей зависимостей, на нём самом написанном, в отличие от перлопитонов, он не тащит. Да, сам рантайм получается слегка тяжеловесом, но зато прекрасно работает на любой совместимой платформе.
Это если разведение гадюшников (или даже автоматизация этого процесса) является нормой сопровождения "систем". Так-то много чего возможно statifier'ом каким утрамбовать в один исполняемый файл.
Разведение гадюшников - это к пыхтону с его venv.
И отдельно к перлу с его бардаком.
В смысле утрамбовать? PHP - реально представляет из себя один-единственный бинарь при статической сборке. И даже при динамической сборке, но в этом случае он совместимые внешние либы потребует. В худшем случае - ещё конфиг можно рядом положить.
С Go не перепутали?
Нет, не перепутал. У того рантайм надо тащить в каждом собранном бинарнике каждой тулзы, а у PHP при желании выходит один на все скрипты. При этом скрипты можно независимо апдейтить без пересборки, что местами важно.
Суёшься в перл - начинается бесконечный поиск пакетов с пакетами, если в дистре не оказалось - велкам ту CPAN, и тут начинается конфликт с тем, что в дистре. Суёшься в пыхтон - то же самое, только скорее всего вообще придётся виртуальное окружение подавать, потому что с системным вообще не разъехаться. Короче, вы поняли.
tcl?
Why not?
Для тех, кто уживается с его синтаксисом - вполне.
И (androwish)[http://androwish.org] его.
CORE::* в perl достаточно для рядовой автоматизации. А продуманная и стандартная библиотека позволяет решать остальные задачи. Может понадобиться работа с датами, бд, асинхронщина и прочее lwp с tt. Но они стабильны по интерфейсам и, часто, уже есть.
Угу. Как только доходим до HTTP, что в перле, что в пыхтоне начинается лютейший ад и всё прочее.
В PHP же опять же всё в рантайме. А скрипты отдельно, что и требуется.
>Как только доходим до HTTPдальше можно не продолжать, у хттп проблемы встроены.
> Суёшься в перл - начинается бесконечный поиск пакетов с пакетамиНа уровне глубины shell-а базовой поставки вполне достаточно.
Ну, кому как.
Лисп схему встроить прямо в ядро.
> Лисп схему встроить прямо в ядро.Схема более похожа на Алгол, чем на Лисп. (Ну ,(кроме скобочек) `конечно)
Недавно перетаскивал LinOTP на восьмую ветку CentOS'а.
Пришлось допилить: сам LinOTP (свежий при том), его перловый скрипт к радиусу, пару питоновых либов - потому, что перловые модули и либы, с которыми эта дрянь совместима, уже либо deprecated, либо всё, один перловый модуль всё уже года три, одна питоновая либа не собирается без патча, одна требует замены. Печаль-беда.
(я уж молчу о том, что он требует мёртвенького python2)
Попробуйте хотя бы разделить наработки с апстримом -- вдруг при виде Ваших страданий и они сподвигнутся что-то сделать.
С апстримом мёртвых deprecated библиотек, которые он хочет?
:D
были ли расмотрены (и отброшены) варианты:
1) выкинуть LinOTP, заменить на более пригодный аналог;
2) выкинуть CentOS, заменить на более пригодный аналог;
3) остаться на CentOS 7, поддерживать своими силами или подрядчиками по найму.
?
> были ли расмотрены (и отброшены) варианты:
> 1) выкинуть LinOTP, заменить на более пригодный аналог;Учитывая, что с ним работать не мне - рассмотрено и отброшено. На него завязаны какие-то проприетарные железки помимо того.
> 2) выкинуть CentOS, заменить на более пригодный аналог;
Не рассмотрено и не отброшено, в сети более-менее гетерогенная среда.
> 3) остаться на CentOS 7, поддерживать своими силами или подрядчиками по найму.
То же самое, что в п.2, перевод старого бардака из другой компании на общую гетерогенную среду.
Простите, гетерогенная = гомогенная.
> Простите, гетерогенная = гомогенная.имено что "гомо".
такая среда даже внутри Microsoft не живет. хотя у них все свое,
чего нету - можно либо купить, либо дать задание программистам и они напишут аналог.но некоторые недалекие CIO продолжают продолжать, все надеются загнать
под какой-то там "стандарт".вот и думайте.
Идеал, я так понимаю, зоопарк из полутора локалхостов, на одном убунта, на другом гента, на третьем арчик, и всё это погоняет центосов с оелами, и альтами до кучи?Не, пока это десяток локалхостов - всё нормально. Но когда число машин начинает измеряться сотнями и десятками сотен - поневоле приходится делать всё стандартно.
> Идеал, я так понимаю, зоопарк из полутора локалхостов, на одном убунта, на
> другом гента, на третьем арчик, и всё это погоняет центосов с
> оелами, и альтами до кучи?если какие-то задачи (кроме сдохнуть первым и предупредить что так делать не надо) лучше выполняет арч, то пусть будет арч. гента вообще сомнительна, но если есть спецы по ней то почему нет. убунта дериватив, зачем оно. альт не нужен если вы не намерены демонстрировать импортозамещение. центос был железобетнонный (и жрал ресурсы), сейчас не знаю что ему на замену.
показательно что вы не вписали в зоопарк ни винду ни *BSD. а есть ниши и для них.
> Не, пока это десяток локалхостов - всё нормально. Но когда число машин
> начинает измеряться сотнями и десятками сотен - поневоле приходится делать всё
> стандартно.и все будут работать одинаково хреново.
как в армии - пусть безобразно, зато единообразно.
Конечно не вписал.
Винда - это задача уже другой команды, там свои заморочки.
BSD вообще телега с квадратными колёсами.
> Конечно не вписал.
> Винда - это задача уже другой команды, там свои заморочки.ну вот видите. а контора-то одна, и сеть общая.
и где ваша желанная гомосреда ? нету !> BSD вообще телега с квадратными колёсами.
тем не менее ниша для нее есть.
> ну вот видите. а контора-то одна, и сеть общая.
> и где ваша желанная гомосреда ? нету !Если чуть-чуть включить мозг и понять, что среды две (а то и более) - есть :)
> тем не менее ниша для нее есть.Есть, конечно, но не в моём случае.
Если собираешься "взакрытую" допиливать ядро под какую-то узкую задачу и продавать, лучше бзды не найти.
> Если собираешься "взакрытую" допиливать ядро под какую-то узкую задачу и продавать, лучше
> бзды не найти.не только. например если надо поставить хост, который сломают в последнюю очередь.
и не потому что "высокое качество кода", а потом что нестандарт.
Security through obscurity?
Учитывая, что качество review явно разнится, даже так лучше нет.
> Security through obscurity?bullshit through bullshit.
вернитесь в реальность. что чаще всего ломают потоковым методом ? то, чего много.
разумеется, узконаправленных взломов под заказ это не касается.
> bullshit through bullshit.Очень правильное определение для ниши, указанной выше.
А то может получиться в первую, а не в последнюю.
А если бы всё это было написано на shell?
> А если бы всё это было написано на shell?ит-салаги исполняли бы это в bash, удивлялись тормозам и приняли бы решение - все переписать на ... [впишите сами].
Я, собственно, хотел намекнуть, что пример не релевантен.Всякую скриптоту вокруг автоматизации рутинных задач прекрасно выполняют perl и python, тем более, что есть из коробки. Я предпочитаю perl, потому что ещё нужен aix, в котором питон надо ставить отдельно.
Повершелл прекрасен именно под виндой, для работы с объектами АД, дотнет, самой винды и вот это вот всё.
Если нужно по простому прочекать какой-то файл, переложить его оттудова сюда, ну и капнуть в лог, я возьму perl (python). Оно будет работать везде, от винды до любого юникса, практически без изменений.
>Я: А ты в курсе что твой скрипт должен работать в том числе на Debian7 и Centos6?А он в курсе, что printf в утилитах не обязан быть стабильным?
Кросплатформенностью? шелл-то и кросплатформенностью?!
Херня вызывающая другую херню и полагается, что на целевой системе будет хотя бы корютилс без чудес.
> шелл-то и кросплатформенностью?!Херня вызывающая другую херню и полагается, что на целевой системе будет хотя бы корютилс без чудес.
Вот вот.
Кто мешает писать на питон 3.5?
Питоны разных версий уживаются в одной системе. Что мешает поставить рядом Python посвежее, если скриптователю захотелось наипоследних фич?
> shell скрипты обладают хорошей кросс платформенностью в linux-unix средеТолько если писать на чистом баше, как только вызвал внешнюю утилиту - не факт что она будет установлена на другом экземпляре той же версии дистрибутива
Да что ты такое, чёрт-побери несёшь? Тебя страшно "обидел" кто-то? или ковид мозг совсем не пощадил?
>> shell скрипты обладают хорошей кросс платформенностью в linux-unix среде
> Только если писать на чистом баше, как только вызвал внешнюю утилиту -
> не факт что она будет установлена на другом экземпляре той же
> версии дистрибутиваНу так это не проблема скрипта. Скрипт -- это софт. Софт пакуется в пакеты, а у пакета есть зависимости, которые уже резолвиться должны пакетником.
Пакет сложно? Ну окей, есть масса альтернатив. Можно например просто писать роли на ansible, которые при установке скрипта будут устанавливать и его зависимости. Как бы, возможностей масса, используйте. Это и есть хорошая кроссплатформенность.
>shell скрипты ... имеют открытый кодА скрипты на Python имеют закрытый код?
>shell скрипты обладают хорошей кросс платформенностью в linux-unix среде, имеют открытый код, не требуют сторонних библиотек или модулей языка.Ха! Да щаз!
Это когда баш перестал быть сторонней библиотекой?Оно ни разу не кроссплатформенно, потому что окружения разные, не везде баш то есть, не везде есть нужные утилиты и не везде они работают одинаково.
У шелл скриптов нет механизма абстрагирования от конкретного окружения.
>У шелл скриптов нет механизма абстрагирования от конкретного окружения.Есть, busybox лиш подтянуть нада.
Ну это же было сделано двести лет до нашей эры. Не модно и не молодёжно.
Ощибка это SystemD, JavaScript, Electron, dart или как его там от гугла вместе с go.А shell отличная вещь для своих целей. Прост, логичен, понятен и с отличной переносимостью.
Не надо от него требовать то, на что он не был расчитан и будет счастье.
> Ощибка это SystemD, JavaScript, Electron, dart или как его там от гуглаСогласен.
Но вынужден дополнить. СистемаД решает таки реальные проблемы которые горе шелл погромисты так и не удосужились решить за всё время сещуствования GNU/Linux.> вместе с go.
Не согласен принципиально. Го отличный инструмент для решения конкретных задач.
> А shell отличная вещь для своих целей.
Он решает проблемы которых как класса не должно существовать.
И круг этих задачт очень узок. Точно не инит системы и не система контроля версий.> Прост, логичен, понятен
Примерно как брейнфак.
>и с отличной переносимостью.
Ох нет. В других комментариях уже объяснил почему нет.
> Не надо от него требовать то, на что он не был расчитан
> и будет счастье.Не надо.
>> А shell отличная вещь для своих целей.
> Он решает проблемы которых как класса не должно существовать.Лол. Не угодно ли местному балаболу обозначить задачи, для решения которых существует shell? Вот те самые, которых не должно существовать. =)
Интересно стало что он обозначит.
> Интересно стало что он обозначит.Ах не угодно. Ну-ну. )
>> Интересно стало что он обозначит.
> Ах не угодно. Ну-ну. )Тебе не угодно? Что ты сказать вообще хочешь? Объясни себя.
> Тебе не угодно? Что ты сказать вообще хочешь? Объясни себя.Я хочу сказать, что с балаболством вроде следующего...
> Он решает проблемы которых как класса не должно существовать.
...становится вполне очевидно, что либо ты имеешь неправильное представление о том, какие задачи решает шелл, либо вовсе понятия не имеешь, зачем этот инструмент нужен.
Вот я тебя и спрашиваю о том, какие-такие проблемы решает шелл, которых якобы не должно существовать как класса.
PS: Ну и собственно прикинуться дурачком, мол, "я не понимаю, что вы мне говорите" -- ну такой себе подход. Веди себя нормально, глядишь, найдётся пара умных людей, которые объяснят тебе, что к чему. А безапелляционно вбрасывать чепуху -- это метод нафлудить с три короба, но ничему так и не научиться. Ибо люди любят делиться знаниями, но только в том случае, если вторая сторона демонстрирует готовность их принимать.
>Вот я тебя и спрашиваю о том, какие-такие проблемы решает шелл, которых якобы не должно существовать как класса.Нет, ты грязно меня оскорбляешь. Или в твоей семье нормально таким образом обращаться к людям с вопросом?
>глядишь, найдётся пара умных людей, которые объяснят тебе, что к чему.
Ты чего-то не понял, но объяснять нужно для меня?
>Ибо люди любят делиться знаниями, но только в том случае, если вторая сторона демонстрирует готовность их принимать.
Ты не демонстрируешь готовности принимать знания, равно как и минимальной вменяемости.
Ты решили отказаться от данного тебе шанса быть человеком, и не постыдился прямо признаться в своем отвратительном мерзком хамстве. Что говорит о том, что ты даже не осознаешь насколько твое поведение мерзко и недопустимо ни в каком обществе.
Буду говорить прямо:
Ты меня со своим отцом балоболом перепутал, отвали от меня, безмозглый переросток.
>...становится вполне очевидно, что либо ты имеешь неправильное представление о том, какие задачи решает шелл, либо вовсе понятия не имеешь, зачем этот инструмент нужен.Почти не спал последние дни, а тут вы явились, нужно быть все-же добрее.
Помогу пожалуй вашим кипящим шестеренкам с рефлексией.
В диалоге вы допустили банальную логическую ошибку, когда решили, что, ваша неспособность что-то понять, означает ошибочность рассматриваемых утверждений, а не нехватку вашей квалификации.
В свою очередь, эта ошибка явилась следствием ошибки более глобальной, вы уверились в том, что будто бы вам известно всё на свете досконально и окончательно.
А ведь даже далеко не все Боги могут называть себя всевидящими и всезнающими. Ну не возомнили вы себя высшим божеством?
Если даже не каждому Богу дано, то с человека то что взять? Человек ограничен в своих знаниях. Букашка, амеба, вирус пошлый. Куда людям до Богов, ну?В свою очередь от чего у вас такое чувство вообще возникло? А это особенность белковой вообще и человеческой в частности физиологии. Мозг очень энергозатратный орган. Думать людям физически больно, как пытка, и больше пары минут невозможно никак, опыты это показывают однозначно.
Большую же часть времени, когда человек пытается решить какую-то задачу, его мозг находит по шаблону "решение" которое "похоже" на правду, и подсовывает в качестве верного единственно ответа. Человеку познавшему Истину, думать больше ненужно, прививки хорошо, курить плохо, запад злой, путен добрый, 2+2=4, на ноль делить нельзя, нефть из мёртвых двинозавров, и так далее. Соответственно, если регулярно не заставлять себя думать, появляется чувство, что известно тебе уже всё на свете абсолютно.
Ведь что бы вы не спросили, ответ всегда тут-же вам мозг выдает, а если что-то не сходится, или заминка получается, то просто собеседник дурак и ничего не понимает - то-же очень простой ведь ответ, всё объясняет и мозги напрягать абсолютно ненужно, а это главное.
> Почти не спал последние дни, а тут вы явились, нужно быть все-же добрее.Надо же. На меня похож.
Окей, я по жизни на редкость злая сволочь (по мнению некоторых), но тоже попробую быть добрее. На то есть несколько причин. Во-первых, после оскорблений ты наконец-то начал вести осмысленный диалог, о чём свидетельствует пост, на который я сейчас пишу ответ, во-вторых ты в этом посте написал почти слово в слово всё то, что я имел сказать тебе, и в-третьих твои посты, где ты восхищён racket-ом, показывают, что мозг у тебя есть, и он жив.
=== Оскорбления и рефлексия ===
Так вот. Ты под этой новостью написал целую серию крайне дерзких, совершенно безапелляционных заявлений о том, что шелл -- это ужас, жуть и мрак, что эта технология изначально была ошибкой, что это бредовая штука, что даже питон (питон, карл! питон, ёпрст!) лучше, чем шелл, что ближайший аналог шелла -- это брейнфак.
Всё вышеперечисленное -- было голословными оскорблениями хорошей технологии, и именно поэтому я тебя оскорбляю: приводи ты аргументы и обосновывай свои тезисы должным образом, был бы диалог. Когда диалога нет, а есть голые стейтменты столь возмутительного характера -- то это повод оскорблять. Всегда.
Единственное, что ты попытался обосновать -- это то, что шелл не является по твоему мнению кросс-платформенным. Но ты решил в качестве аргумента упирать на то, что не везде утилиты, объединяемые шелл-скриптом, будут в наличии, а также не всегда эти утилиты ведут себя одинаково (видимо, ты про различия coreutils и bsdutils как минимум). Но это крайне слабый аргумент. Сам шелл -- кросс-платформенный инструмент. А вот скрипты имеют зависимости. И обеспечение наличия нужных тулзов -- это задача того, кто скрипт в систему, собственно, ставит. Довольно очевидные вещи.
Итого. Ты оскорбляешь хорошую технологию, отличное знание которой лично мне как опсу (а в прошлом -- racket- и ocaml-программисту) очень и очень помогает по жизни, и особенно -- в кризисных ситуациях (масса историй). Аргументы либо отсутствуют, либо плохие. Я надеюсь, что теперь ты понимаешь, чем именно ты заслужил отношение, которое имел неудовольствие читать выше по треду. Я просто спесь сбивал. И как видишь -- с результатом.
=== Адекватая замена shell ===
Так вот, вернёмся к вопросу о задачах, для которых создавался и используется шелл. Шелл решает ровно одну задачу: организацию конвейера параллельно исполняющихся процессов. И он решает её хорошо. Утверждать, что это ошибочный ход, значит противоречить принципам UNIX, на основе которых построена вся наша экосистема nix-подобных осей.
Ты предлагаешь Rash как альтернативу стандартному шеллу. Что ж, штука конечно интересная, но есть несколько замечаний к такой альтернативе.
1) Ничто не мешает делать конвейерные вставки на лиспе и в обычном шелле путём оборачивания в функцию вызова интерпретатора с лисп-кодом внутри, так в чём же тогда суть? Сисадмины годами так дёргали и питон, и перл, и много чего ещё.
2) Попытка сделать шелл языком общего назначения, чтобы он мог нести в себе логику преобразования сложных структур данных -- обречена на провал. Потому что, ещё раз повторюсь, шелл решает ровно одну задачу (см выше). И ему не нужно брать на себя большего, ибо как раз это -- ошибочный ход, являющийся следствием непонимания того, чем шелл является. Любая дополнительная логика должна быть выполнена иным инструментом. Например, при помощи awk, jq/yq, sed...
3) Даже если шелл и делать языком общего назначения, то sexp-ы явно не лучший выбор. У лиспов очень высокий порог вхождения. Людей, которые способны вести разработку, держа в голове деревья и продумывая то, как они будут сворачиваться -- ничтожно мало. Такой язык просто не будут использовать. RMS тоже когда-то хотел видеть лисп в качестве языка системного программирования, но время показало, что этому не бывать.
4) Rash не posix compliant. Что делать со скриптами, написанными на posix shell? Выбрасывать? Нет, никто этого делать не станет. И переписывать тоже. Это будет просто глупая трата времени. Обратная совместимость -- это важно. Даже тот же Emacs на Guile перенести не могут вот уже не первое десятилетие, потому что стремятся сохранить обратную совместимость с уже написанными пакетами на Elisp, ибо без них Emacs нафиг никому не нужен.
=== Конвейеры ===
Ты вот утверждаешь в одном из постов, что передавать объекты и коллекции в конвейере -- это хорошо и правильно. Что ж, я как функциональщик отчасти с этим тезисом согласен. В конце концов когда мы ведём разработку на функциональном языке -- мы именно тем и заняты, что пишем такие конвейеры. Но вот в чём суть: хорошо ли это для шелла?
Шелл в текущем виде выстреливает прежде всего потому, что он организует конвейер именно для текстовых потоков. Любые иные потоки данных -- редкость, и в принципе неправильный подход. Неправильный, потому что поток текста -- сущность понятная всем пользователям, которая встречается наиболее часто, и которую удобно использовать. А если в конвейере начинают передаваться иные сущности, будь то картинки или ассоциативные массивы, или что угодно ещё -- то следом возникает необходимость проверки типа передаваемой сущности, необходимость держать это в уме при разработке скрипта, необходимость вставлять множество дополнительных проверок (ну не просто же так в racket-е существуют контракты, да?). Если всё это вставить в шелл, то честное слово, почему бы вместо шелла не писать сразу уже на racket-е? Или на perl? Или на чём угодно ещё?
Нет, shell выстрелил именно потому, что он не делает лишнего. Иногда сужение области применения -- это хорошо. Это помогает сохранить простоту чтения и понимания, что для скриптового языка, имеющего ограниченную область приложения, крайне важно.
=== Заключение ===
Ну вот, я потратил аж целых полчаса, и надеюсь, что-то донёс. Твой ответ покажет, имело ли всё это смысл.
От себя пожелаю -- больше спать. Нужен режим дня. Разум не существует отдельно от тела, как бы может того ни хотелось некоторым из нас. Если подзапустить тело, то и разуму будет нанесён ущерб. А без разума -- является ли гуманоидное существо человеком? Вот пишешь в сеть пост, и никогда не знаешь, кто на другом конце сидит. Человек или...
PS: Силу шелла не стоит недооценивать. Вот кто-то скажет, что find -- просто ищет файлы, а кто-то -- что она обходит дерево каталогов. И разница в понимании сути данной утилиты между этими двумя людьми -- огромна. То же самое и с шеллом.
>Так вот. Ты под этой новостью написал целую серию крайне дерзких, совершенно безапелляционных заявленийВы путаете свой внутренний мир с внешней реальностью.
То что вы обиделись, еще не означает что вас кто-то обижает.>Всё вышеперечисленное -- было голословными оскорблениями хорошей технологии, и именно поэтому я тебя оскорбляю
Я то прекрасно понимаю почему вы пишите то что пишите, вы не понимаете что я понимаю. Это детский сад, на что я вам прямо уже указываю.
>Так вот, вернёмся к вопросу о задачах
Вы мне ничего нового не сообщаете, примерно чего-то такого я от вас и ожидал услышать.
Для вас эти шеллы очень волнующи, вы в этом живёте. А для меня нет.
Вы смотрите с точки зрения конкретного опыта эксплуатации конкретных UNIX систем, а я рассматриваю их с концептуальной точки зрения. С точки зрения вычислительной техники в человеческом обществе.Не думаю что я в настроении обсуждать технологии. Может позже вернусь к этому.
Разве что на это отвечу пока:
>У лиспов очень высокий порог вхождения.(функция аргумеент1 аргумеент2 .. аргумеентN)
Поздравляю, вы знаете лисп.>Людей, которые способны вести разработку, держа в голове деревья и продумывая то, как они будут сворачиваться -- ничтожно мало.
Чтобы на лиспе писать ненужно в голове деревья держать. Вы просто следуете ряду простых правил доступных каждому, и получаете рабочую программу. При условии, что вы сами понимаете что программа ваша должна делать. Не зря же на нём детей учат программированию.
Могу порекомендовать https://htdp.org к вечернему прочтению, чтобы заиметь представление о том что это такое вообще.
>> У лиспов очень высокий порог вхождения.
> (функция аргумеент1 аргумеент2 .. аргумеентN)
> Поздравляю, вы знаете лисп.<имитация пользователя>
Ммм, здорово. Значит первой в sexp-е стоит функция. Всё понятно! Тогда...
(apply and list-of-bools)
</имитация пользователя>Уже на этом моменте ты можешь задуматься наперёд и спрогнозировать количество моментов, где пользователи встрянут в глубоком непонимании на очень долгое время. Да что там. Ты что, не замечал, как много людей не просто не понимают рекурсии, но даже считают её злом (а то как же, в сишечке же стек продавливается). И они работают в сфере IT. Казалось бы, не должны, но потребность в рабочей силе в нашей сфере гораздо больше, нежели есть квалифицированных специалистов. Бизнес в таких условиях задирает цены, а на такие предложения слетается целая свора профнепригодных, прошедших месячный курс питон-программиста на каком-нибудь скиллбоксе.
Ты правда думаешь, что двигать этим людям лисп -- разумно? Дай обезьяне ружьё, ага. Даже если она разберётся, она ж себе ногу отстрелит.
> Чтобы на лиспе писать ненужно в голове деревья держать. <...> Не зря же на нём детей учат программированию.
Серьёзно? Где? Даже в MIT уже SICP студентам не читают. В связи с чем...
> Вы путаете свой внутренний мир с внешней реальностью.
...ты думаешь, что я? =)
>Ты правда думаешь, что двигать этим людям лисп -- разумно? Дай обезьяне ружьё, ага.Обезьянам нужно в джунглях сидеть.
О чём вы вообще? Люди в большинстве не такие тупые как вы пытаетесь это показать. Вы так своё самолюбие тешите?
>Шелл решает ровно одну задачу: организацию конвейера параллельно исполняющихся процессов.Если процессы ненужно исполнять параллельно то шелл ненужен? Например одна программа требует вывод завершившийся другой программы?
Есть ли шелл на однозадачных системах? MS-DOS имеет шелл или не имеет?
Меняется ли что-то если "процессы" не использую стандартную Cи библиотеку?
Что если у них нет потоков ввода вывода?>Утверждать, что это ошибочный ход, значит противоречить принципам UNIX, на основе которых построена вся наша экосистема nix-подобных осей.
Вы верно меня поняли, но для вас это предположение слишком возмутительно чтобы рационально его обдумать.
>> Шелл решает ровно одну задачу: организацию конвейера параллельно исполняющихся процессов.
> Если процессы ненужно исполнять параллельно то шелл ненужен? Например одна программа требует вывод завершившийся другой программы? Есть ли шелл на однозадачных системах? MS-DOS имеет шелл или не имеет?Уууу, какая софистика пошла в ход. То есть тебе вот прямо-таки хочется именно чтобы последнее слово за тобой осталось, что ты готов вспомнить историю шеллов, выкопать COMMAND.COM, обсудить, чем они были во времена однозадачных систем? Вот прямо-таки бить себя в грудь: они же тоже назывались шеллами! =)
Жаль. Ведь именно на этот случай я написал PS про find.
>> Утверждать, что это ошибочный ход, значит противоречить принципам UNIX, на основе которых построена вся наша экосистема nix-подобных осей.
> Вы верно меня поняли, но для вас это предположение слишком возмутительно чтобы рационально его обдумать.Так обдумывать тут нечего, ты ж ничего не предлагал. =)
К тому же, я не знаю, насколько наивным дундуком надо быть, чтобы после предыдущего моего поста предположить, что я не обдумывал подобные концепты ранее. И ведь мог спросить, но нет. "Это предположение слишком возмутительно, чтобы рационально его обдумать". Фанбой, как же ты не понимаешь, что мы "ретрограды" только в твоём воображении? =)
>и включает компоненты на языках Python, Shell, C и OCaml.а почему не просто тока православный С ? зачем такой огород городить ?
В Gentoo тоже похоронили Paludis на Си и пользуются Portage на питоне. Кто их знает, может им проще было. Лет через много когда будет требование к многопоточности обязательным может и выкинут все кроме Си и шелла.
Такими темпами лет через много дженту просто перестанет существовать. Если тренд набирающий обороты таки победит, в дженту просто не будет никакого смысла.
А там еще и смуззяшные питоняши дотянуться ручками до портажных питонов и заверте..
> В Gentoo тоже похоронили Paludis на СиНикто никого не хоронил. Активная фаза разработки Paludis завершилась, а в portage стали резво внедрять новые EAPI... Внедряли по делу (кросскомпиляция в EAPI 7/8 наконец-то стала работать адекватно).
А paludis сам собой отстал и поломался. Пострадал не только paludis, но и всякие мелкие утилитки из app-portage. Одни ROOT=/usr/aarch-linux-gnu/ игнорят, другие REQUIRED_USE не умеют, третьи CHOST от CBUILD не отличают и т.д.
Потому что переизобретать bash для разбора в AST, видимо, не хотелось. Интересно, пробовали ли взять его парсер или сразу было понятно, что для таких преобразований именно что более высокоуровневые структуры данных нужны?..PS: imz@ как-то написал cuglify -- транслятор диалектов языка C; ему для этого пригодился Haskell:
http://hub.darcs.net/imz/cuglify (начинать осмотр стоит с ann*.md)
http://lvee.org/ru/abstracts/185
http://lists.altlinux.org/pipermail/devel/2016-February/2008...
Ох нихрена ж они заморочились.
>Проект PaSh, развивающий инструменты для параллельного выполнения shell-скриптов, ... Linux Foundation, ... Код проекта распространяется под лицензией MIT и включает компоненты на, ... Shell, ...Яснапонятно. Какой, именно Шелл, неужели Маздаевский PowerShell?
Они ничего не слышали о GNU Parallel.
Полагаю, это Вы не дочитали до букв JIT.// давний пользователь parallel, пакет с которым в альте и поддерживаю
PaSh - удар по systemd'ерам.
> включает компоненты на языках Python, Shell, C и OCaml.И этот комбайн только из-за того, что поленились почитать мэнуал и узнать о чудо фичи - "&"
которая запустит в субпроцессе паралельно любую из задач непосредственно из скрипта...
Это просто арктический лис какой-то, пригнать кран, бульдозер и ракету чтоб помочь велосипеду переехать дорогу
Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по числу ядер на шелле (не считая утилиты вроде xargs и parallel). Зато осилил IPC на шелле (вообще без проблем) и фоновые процессы на шелле (изично, только как завершать их нормально, чтоб слип не провисал, тоже не представляю -- приходится убивать). Эти ребята решили проблему несколько иначе, и шел им просто лишний как по мне. Да и вообще, есть подозрение, что это чисто по фану.
> Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по
> числу ядер на шелле (не считая утилиты вроде xargs и parallel).how_many_cpu() {
lscpu | grep 'On-line CPU' | awk -F: '{print $2}'
}> (изично, только как завершать их нормально, чтоб слип не
> провисал, тоже не представляю -- приходится убивать).( echo 'Job #1 started...'; sleep 5; ) &
pid=$!;echo "Do some other stuff in parent's process ...";
echo 'Waiting 4 job#1 to finish gracefully'
tail --pid=$pid -f /dev/null;
echo $?> Эти ребята решили проблему
> несколько иначе, и шел им просто лишний как по мне. Да
> и вообще, есть подозрение, что это чисто по фану.Эти ребята классическое представление интерпрайза, где деньги не свои и можно поиграться со всем новеньким и ублажить мэнеджера, что они используют новейшие технологии, а в итоге строют мостра, вместо того чтоб разобраться с инструментом, который они собираются "улучшать"
>lscpu | grep 'On-line CPU' | awk -F: '{print $2}'Зачем так сложно? nproc
Можно даже (отсторожно башизм) $(($(nproc)*4)) если хочется по 4 процесса на ядро запустить
Ах, если бы всё так просто было… Я конечно в порядке развлечения сделал всё на шелле, но вывод я поучил только один: нужны скрипты -- бери питон и не страдай хернёй, особенно, если требуется параллельное исполнение.
Кусок давно и успешно работающего кода параллельно запускающего сканирование в 300+ потоков на 6 ядрах процессора:
for th_count in $(seq 1 $threads_run)
do
domain_scan "$th_count" &
done
joblist="$(jobs -p|sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g')"
Не хочу обидеть никакие языки программирования, но чем дольше работаю с шелом, тем реже возникает желание/надобность что-то к шелу добавлять (даже однострочники на разных ЯП)Вышеуказанный код позже был переписан с использованием Gnu Parallel (что улучшило работу скрипта), но внедрение нового скрипта пока затянулось по бюрократическим причинам
Так это совершенно мимо: ведь задача не наспавнить процессов, а спавнить новые покуда есть данные. При завершении родительского процесса (а ля sigint/sigterm) все порождённые процессы должны быть тут же завершены (включая все эти слипы), а готовые уже результаты сохранены.
Совсем не мимо. Скрипт именно так и работает: читает из файла 100500мильенов строк входных данных, разбивает входные данные на N частей, параллельно обрабатывает все эти N частей. Обработка результатов запущенной в N потоков ведется другим участком кода, который я не приводил выше, чтоб не захламлять обсуждение кодом
Я просто не заметил того кода, с которым у меня возникли проблемы в шелле, а именно -- синхронизации процессов и обработки завершения. В лучшем случае у меня получалось так, что под инитом оставалось висеть куча разрозненных провисших процессов после завершения скрипта. Всё же, в питоне куда проще решать такие задачи. И jobs -p это конечно хорошо, но вообще никуда не годится по факту. Я тоже сначала был доволен своим наколенным кодом, повезло, что довольно быстро обнаружил, что тот делает совсем не то, что я ожидал.
У приведенного мной выше кода есть еще такой минус. Если одни потоки завершаются раньше, то в принципе на их место можно было бы запускать другие, но данные разбиты на части перед распараллеливанием и это невозможно. Поэтому время работы равно времени работы самого долгого из потоков.
В принципе можно было решить эту проблему без использования Gnu Parallels, но я решил с использованием и получил заметное ускорение и уменьшение расхода ресурсов (ну правда изменения не ограничились parallels)
А как же провисшие процессы? И gnu parallel это perl. Мне не нравится автор и особенности синтаксиса этой утилиты. Теперь использую xargs везде, где можно решить вопрос распараллеливания запуском нескольких копий скрипта в цикле (единственная задача при этом писать скрипт так, чтобы можно было спокойно запускать сколько угодно его копий для разных данных). Для фоновых процессов всё ещё использую ipc через файлы, и завершаю через pkill -g $$. Спасибо, что есть find -print0 и xargs -0, иначе всё было бы очень печально (привет любителям бсд).
>А как же провисшие процессы?Что значит провисшие? А, точно я упустил еще одну строчку, которую надо было привести в примере выше (гранд пардон):
joblist="$(jobs -p|sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g')"
echo "$(date +%Y-%m-%d:%H:%M:%S) $th_count threads started"
wait $joblistwait будет ждать, пока все потоки не обработают свои данные и не завершатся. Только тогда пойдет выполнение дальнейшего кода
Допустим, там фоновый жоб в таком формате while sleep 600 & wait; do и если скрипт завершить (отправив kill всем фоновым процессам напоследок), то sleep остаётся висеть. Я тогда словил гонку в нескольких местах сразу (и кажется, что работает, а по факту 1/10 раз нет).
Согласен, подобное может быть проблемой, но не мой случай. Все запущенные в потоках команды/программы сами завершаются в течении 8 секунд по таймауту, если запустивший их процесс убить, но мне никогда не требовалось этого делать пока скрипт со всеми потоками не выполнит свою задачуНо думаю, что и эта проблема решима, если старательно к ней подойти
> Но думаю, что и эта проблема решима, если старательно к ней подойтиhelp ulimit, однако...
> Спасибо, что есть find -print0 и xargs -0, иначе всё
> было бы очень печально (привет любителям бсд).https://www.freebsd.org/cgi/man.cgi?find(1)
-X Permit find to be safely used in conjunction with xargs(1). If a
...
However, you may wish to consider the -print0 primary in
conjunction with “xargs -0” as an effective alternative.-print0
This primary always evaluates to true. It prints the pathname of
the current file to standard output, followed by an ASCII NUL
character (character code 0).
И тебе привет.
Ну норм, это правда findutils. Чё там по coreutils?
>> Спасибо, что есть find -print0 и xargs -0, иначе всё
>> было бы очень печально (привет любителям бсд).
> Ну норм, это правда findutils. Чё там по coreutils?Ну норм спрыг. Погоди, щас шнурки поглажу ...
Отчасти, ты прав конечно, только ведь это одна и та же проблема. Есть ещё прекрасная конструкция for file do (и find тут очень при чём), это вроде башизм же? И тут GPL…
> Отчасти, ты прав конечно, только ведь это одна и та же проблема.
> Есть ещё прекрасная конструкция for file do (и find тут очень
> при чём), это вроде башизм же? И тут GPL…Я нхнп. Особенно - причем тут GPL.
А бсдшный sh (который именно sh, с реализацией в 13 000 sloc) вполне себе переваривает
for f in *; do printf "%s\n" "$f";done-.o
-.s
[RPF] Обратная сторона Власти.zip
если что.
нет, я имел в виду for file do -> find -c 'for file do;echo $file; done' sh {} +
> ведь задача не наспавнить процессов, а спавнить новые покуда есть данныеИменно это xargs -P и делает.
> Не хочу обидеть никакие языки программирования, но чем дольше работаю
> с шелом, тем реже возникает желание/надобность что-то к шелу добавлять
> (даже однострочники на разных ЯП)А книжку "UNIX: универсальная среда программирования" (Керниган, Пайк) помните?
>бери питон и не страдай хернёйЗабыл как Мариванна говорила: "На ноль делить нельзя!"
>> Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по
>> числу ядер на шелле (не считая утилиты вроде xargs и parallel).
> how_many_cpu() {
> lscpu | grep 'On-line CPU' | awk -F: '{print
> $2}'
> }Вот функция, которая составляет список активных ядер. Пример форматирования в комментарии.
/*
* Returns human readable representation of the cpuset. The output format is
* a list of CPUs with ranges (for example, "0,1,3-9").
*/
char *cpulist_create(char *str, size_t len,
cpu_set_t *set, size_t setsize)
> а в итоге строют мостра, вместо того чтоб разобраться с инструментом,
> который они собираются "улучшать"На эту тему: http://egorfine.com/ru/articles/worse-than-failure/
> tail --pid=$pid -f /dev/null;Это можно даже сказать красивый изврат с tail
Но: как оно себя будет вести если пока
"Do some other stuff in parent's process ...";
фоновый процесс с данным pid завершится и на его место кто-то запустит что-то другое? (гонка)
Не зря же pidfd придумали.
>> tail --pid=$pid -f /dev/null;
> Это можно даже сказать красивый изврат с tail- Почему красивый изврат?
- Красота спасет мир ;)
> Но: как оно себя будет вести если пока
> "Do some other stuff in parent's process ...";
> фоновый процесс с данным pid завершится и на его место кто-то запустит
> что-то другое? (гонка)Ну свой то PID мы знаем ?!
А детишек, свои или нет можно легко проверить на отцовство `ps -o ppid=ххх`
Есть еще куча других методов, но каждый хорош под свою задачу, если здесь добавить обертку на проверки, то смысл примера потеряетсяПример то - не продакш, а просто в тему, что народ нагородил огород из кучи разных языков, хотя могли бы обойтись не квадратной головой и использовать тулз то назначению.
> Не зря же pidfd придумали.
Ну свой то PID мы знаем ?!
А детишек, свои или нет можно легко проверить на отцовство `ps -o ppid=ххх`
Можно пошерстить /proc/$PID/fd и проверить уникальный доступ к чему-либо уникальному (хэш созданный на старте к примеру) ...
Есть еще куча других методов, но каждый хорош под свою задачу, если здесь добавить обертку на проверки, то смысл примера потеряетсяПример то - не продакш, а просто в тему, что народ нагородил огород из кучи разных языков, хотя могли бы обойтись не квадратной головой и использовать тулз то назначению.
> Не зря же pidfd придумали.
pidfd_getfd() "придумали" всего год назад, (насколько я помню, он доступен только с 5.6 кернелом), а еще есть громадная куча парка машин где принцип "работает, - не трогай" и народ вполне обходился и обходится без pidfd (не я не против pidfd, наоборот, но действительность однако...)
> Ну свой то PID мы знаем ?!
> А детишек, свои или нет можно легко проверить на отцовство `ps -o
> ppid=ххх`Скорее ps -o pid --ppid=xxx
но идея понятна, согласен.
Хотя еще возможно придется учитывать внуков (потомков потомков), и не факт что ребенок будет жив пока внук работает. shell - он же может форкаться.
Хотя pidfd тут тоже не поможет в лоб.> Пример то - не продакш, а просто в тему,
А я видел такое в проде, приходилось исправлять.
Вообще, досадно видеть, что есть куча кода, который almost works.> pidfd_getfd() "придумали" всего год назад, (насколько я помню, он доступен только с
> 5.6 кернелом), а еще есть громадная куча парка машин где
> принцип "работает, - не трогай" и народ вполне обходился и обходится
> без pidfd (не я не против pidfd, наоборот, но действительность однако...)Мой поинт был в том, что в pidfd была все же потребность.
Короче дело было так. Был огромный легаси баш скрипт, который работает "не трогай". И они такие "ну что, ускорим?". Вот и ускорили.
> Короче дело было так. Был огромный легаси баш скрипт, который работает "не
> трогай". И они такие "ну что, ускорим?". Вот и ускорили.Аха, или просто был конкурс на https://en.wikipedia.org/wiki/Rube_Goldberg_machine