Если в баше все так плохо, не пора ли перестать им пользоваться для скриптов?

мне кажется я понимаю подход о котором ты говоришь. я предполагал что такой подход должен был использоваться до патченья программ - т.е. создание для каждой существующей программы фала-описания чтобы потом можно было делать #1d (и ещё я думал о именованых потоках вроде #hours #name).

тут проблема конечно в трудоёмкости написания файлов-описаний.

Так что если я понял верно то идея которую я пытался озвучить существует, продумана и реализована в виде линз. выглядит конечно прекрасно. но писать файлы описаний наверное каторга ещё та. если бы программы выводили информацию в именованых потоках, и можно было иметь доступ к ним по чему то вроде #pid или _.pid был бы удобно. но это конечно другой вопрос, следующий шаг так сказать.

ах, вот оно что...

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

в таком случае должен заметить что твой пример выглядит прямо таки волшебно. и всё таки вряд ли легко удасться добиться такой работы без модификации вывода программ и окружения. В смысле чтобы программы писали в именованые потоки, а шелл мог к ним обращаться. Как мне кажется будет много гемороя из за того что идёт сплошной текст. oselect конечно сможет однозначно парсить то что ты подаёшь на вход из proclist-lens, достаточно ковычек и экранирования. Но вот разбор вывода программ мне кажется задачей труднорешаемой в общем случае и именно из за того что идёт текст сплошняком, непонятно где пробел в тексте а где закончился логический блок. Я честно говоря даже мозгом вывод lspci разбираю с трудом большим, куда уж там регулярки писать.

Ну, изначально эта штука делалсь для редактирования конфигов, AFAIK. И, хотя с одной стороны, ей никто вроде не пользуется, она жива и развивается. И кое-что умеет: http://augeas.net/docs/references/lenses

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

Я не вижу смысла в именованных потоках. Можно, наверное, изобразить Hartmann pipeline, но зачем? Сила шелла - в простоте для простых случаев.

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

Я думаю, что в Augeas это решено (они парсят многострочные файлы). Вопрос только в том, насколько сложно писать линзы, и насколько Augeas пригоден для парсинга потока.

Изобретатели велосипедов, блин.

ps -h --user $USER -o vsize,pid | awk -F ' ' '{ if( $1 > 500*1024) { print $2 } }' | xargs kill

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

Сила шелла - в простоте для простых случаев.

так для простых случаев мы сохраняем простоту. В потоке (условно) #0 содержится просто текст как его вывела бы программа без потоков и именно он выводится шеллом на экран. Но внутри программа разбивает свой вывод на подпотоки и передаёт шеллу не результат а каждый поток и правила для сборки потоков в кучу. И если тебе надо просто поглядеть lspci, ты делаешь

$ lspci

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

$ lspci | echo _.address _.model

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

в целом я согласен что если линзы писать легко, то необходимость модификации программ сильно нивелируется. можно просто добавить алиас lspci -> lspci | lspci-lens , правда тогда всплывает вопрос что будет если я просто напишу lspci? а если нужно помнить про lspci | lspci-lens | oselect «_.address _.model» это конечно всё равно сильно удобнее текущего положения, но согласись, несравнимо с lspci | echo _.address _.model

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

почитал вики про Hartmann pipeline - это мне кажется слегка не то. по крайней мере выглядит не так на первый взгляд.

Попытки полить грязью баш просто смешны. Баш это всего лишь реализация стандартов шелла.

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

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

PowersHell SystemD и подобные поделия суть одного поля ягоды. Поделки дилетантов и неосиляторов, завистников.

Жуть какая. Всего-то надо прочитать man lspci на предмет lspci -m и man xargs например.

lspci -m | xargs -L1 sh -c 'echo $0 $3'

Работает здесь и сейчас без всякого там велосипедства.

Работает прям здесь и сейчас, без всяких там

Существующими в Linux средствами можно найти процессы, имеющие RSS больше 500M. Кто бы мог подумать.

Неужто изобретать велосипед проще чем ман об используемых инструментах почитать?

Конечно, ты единственный человек на планете, который знает awk.

А еще такие, как ты, куячили в FoxPro циклы, когда там давно был SQL %)

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

В то время как, скажем, что то вроде

$ _.lspci
address:text
type:text
model:text
producer:text

дало бы тебе возможность незадумываясь моментально написать

$ lspci | echo _.model _.producer

и не надо «немножечко читать ман, немножечко изучать иксаргс». Уровень удобства совершенно иной, понимаешь? соотвественно и производительность труда значительно выше.

Существующими в Linux средствами можно найти процессы, имеющие RSS больше 500M. Кто бы мог подумать.

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

Конечно, ты единственный человек на планете, который знает awk.

Можно и без awk. [ умеет сравнивать числа.

А еще такие, как ты, куячили в FoxPro циклы, когда там давно был SQL %)

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

Существующими в Linux средствами можно найти процессы, имеющие RSS больше 500M. Кто бы мог подумать.

Очевидно те, кто не умеет пользоваться существующими в Linux средствами

На винфак. Проповедуй там.

Можно и без awk. [ умеет сравнивать числа.

Сумеешь сделать это без read и while?

Да мне как-то плевать кто там что использовал

Я вижу.

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

Считанные минуты. В less, который является обычно пейджером для man есть поиск.

и не надо «немножечко читать ман, немножечко изучать иксаргс».

Читать полезно. И всё равно придётся. libastral ещё не изобрели.

Уровень удобства совершенно иной, понимаешь?

Нет, не понимаю. Какая разница - искать в мане по lspci нужный ключик или искать в мане по _.lspci нужное название поля?

Нет, не понимаю.

ок.

На винфак. Проповедуй там.

Так это они сюда за проповедями приходят.

Сумеешь сделать это без read и while?

Легко:

ps -h --user $USER -o vsize,pid | xargs -L1 sh -c '[ $0 -gt 512000 ] && echo $1' | xargs kill

ps -h --user $USER -o vsize,pid | xargs -L1 sh -c '[ $0 -gt 512000 ] && kill $1'

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

мужик, ты правда не вкуриваешь.

Ну да. Не вкуриваю. Зато вы, видимо, вкуриваете по полной. Что-то такое весьма забористое, причём.

или иди в admin помоги неофитам, там твоя энергия будет очень кстати по-моему.

Неофитам лучшая помощь - доки почитать. man program_name там и без меня легко напишут.

На винфак. Проповедуй там.

Так это они сюда за проповедями приходят.

Не припомню, чтобы в этом топике к тебе кто-то приходил за проповедями.

Сумеешь сделать это без read и while?

Легко:

Браво. Ты читал man по xargs.

512000

Характерно. Что ж ты не написал выражение, с полным эскейпингом?

Характерно. Что ж ты не написал выражение, с полным эскейпингом?

С этим тоже у тебя проблемы? $((500*1024))

Никогда так не было.

они вместо n опций лепят n^2 методов!

отрефакторим код, в чём проблема..

Не-е, поздно... Первая фраза самая верная.

Много параметров - это плохо, очень плохо.

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

И всё-таки повторюсь: вот это: Player.playRepeatableRandomDir(«/dir/», «flac, mp3»); — замена n параметров на n в квадрате методов.

Ты еще в Скале количества методов не видел.

И что, это хорошо? Высокий порог вхождения же.

И кстати: в мире shell some_command --help, как правило, выдаёт список возможных опций. А в Скале получить список доступных методов объекта можно? Или их все надо в голове держать?

И что, это хорошо?

Еще как. Методы на все случаи жизни под рукой.

Высокий порог вхождения же.

Не такой и высокий.

Характерно. Что ж ты не написал выражение, с полным эскейпингом?

С этим тоже у тебя проблемы?

У меня - нет. А у тебя - видимо, да, иначе написал бы сразу.

Ой, гляньте-ка, этот дикий ещё и tailgunnerа учит шеллом пользоваться.

Весело у вас тут. У половины есть какие-то гипотетические библиотеки, вторая половина предлагает перейти на Винду с ПС.

мой опыт говорит об обратном.

Тем же, чем и чёрный рис, и поездки в Финляндию за туалетной бумагой.

Значит к проблемам shell ещё прибавляется проблема отсутствия нормальных библиотек, интересно, почему.

А ещё 5 звёзд на лоре. :-(

У меня - нет. А у тебя - видимо, да, иначе написал бы сразу.

По хорошему, математика не во всех sh есть. Так что просто число, всегда предпочтительнее будет.

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

Так может надо было так и сидеть на винде? Там ни манов, ни перлятины, интуитивно-понятный интерфейс и всё такое.

Вот нахрена лезть туда, где всё непонятно и трудно, забывается и всё такое, а потом жаловаться и плакаться?

В некоторых местах такие перлы на Bash, действительно похожи на однострочники. Или на сложные регэкспы. Write once, read never.
А человек имеет свойство забывать. Вот только отвлечётся от Bash на пару месяцев, и знания о нём уйдут глубже, в том числе и память о том, что делает этот гиппотетический кусок перлятины. Это может случиться и с тобой.
И нельзя ругать за это человека. Ты же не ругаешь инвалида-колясочника, за то что он ходить не умеет? Не пользуясь эдак полгодика ногами, можно вполне забыть, как ходить.

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

Ровно до момента, когда в этом питоне что-то не обновится.

к проблемам shell ещё прибавляется проблема отсутствия нормальных библиотек

Ох, понеложство тебя до добра не доведёт.

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

Ровно до момента, когда в этом питоне что-то не обновится.

Не надо грязи. Обновления Python безпроблемны. Обновления библиотек могут что-то ломать, но это проблемы библиотек.

Обновления Python безпроблемны.

Python2 vs Python3?

Обновления Python безпроблемны.

Python2 vs Python3?

Если ты не знал, это два несовместимых языка.

А человек имеет свойство забывать.

Невозможно разучиться ездить на велосипеде или там водить машину.

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

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

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

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

Это невозможно. Могут атрофироваться мышцы или испортится нервные пути - это да, может придётся учиться ходить по-другому, не так как раньше. Но забыть как ходить абсолютно невозможно.

Я предлагаю вариант расширения шелла получше.
Шелл(в данном случае Bash), уже имеет хэши и массивы. Правда хз, можно ли их пихать друг в друга. Если нет, можно сделать такой функционал. Можно подкорректировать синтаксис, но это мелочи.
При желании, программы могут модифицироваться, дабы вместо простого текста, по ключу, или в зависимости от контекста(шелл тогда подаст сигнал. как SIGPIPE), выдавать структурированный хэш, или массив Bash. Разделяя каждый разный «объект» не новой строкой, а используя '\0'.
Сделать в шелле новую встроенную команду «readobj», которая будет пихать один объект за раз в указанную переменную, и парсить его как массив/хэш. А там уже понятно, как с этим работать.
При желании можно сделать массивы и хэши одним и тем же, как таблички в Lua.
Если программа не умеет в объекты, можно будет самому делать «линзы», которые будут сами стркутурировать эти данные, и выдавать наружу объекты.
Хочешь методов? Можно будет в поля просто записывать функции, или адреса функций. Ну и синтаксический сахар для их вызова. Ну или подключаемые модули с функциями, для работы с теми или иными структурами...

В результате получается нечто вроде объединения lua и bash. Хочешь парсить? Парси. Хочешь объекты? Вот тебе.

Но это скорее с bash уже не сделать. Это нужно пилить отдельный shell.

// Не исключаю, что это уже предлагали.

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

Я и не предлагал. Действительно нужно помнить Perl. Но не нужно строить из себя гения. Если ты опеределённое долгое время не будешь видеть этот участок кода, например уволившись с работы, и на заначку отдыхая полгодика, мозг запихает это как «ненужное» куда подальше. Ведь ты не будешь все эти полгода «отпуска» писать программы на Bash?
Этот кусок забудется, и твоему мозгу придётся это либо вспоминать, или парсить вот это заново. (А оно, предположим, выглядит как '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see', и нет ни единого комментария.)
Насколько быстро ты распарсишь, что делает этот кусок? И как делает? Ну или, насколько быстро ты вспомнишь?

Беда любителей «всё есть объект» в том, что при отсутствие интерфейсов - они сосут. А любители текста сначала засучивают рукава и парсят. А потом рожают собственный интерфейс, с верификацией и прочими свистелками, если такие нужны.

Но даже /proc не решает проблему неструктурированности данных.

Вообще-то для любителей программировать есть C API к вызовам ядра - обвызывайся. И там всё структурированно, процессы представляют собой список.

после нормальных языков

Это PowerShell-то нормальный? О боже ж ты мой, да я блюю при работе с ним почище тебя. А приходится, потому что остальное что есть из коробки под оффтопик - еще хуже.

2 чая данному джентельмену

Если ты опеределённое долгое время не будешь видеть этот участок кода, например уволившись с работы, и на заначку отдыхая полгодика, мозг запихает это как «ненужное» куда подальше. Ведь ты не будешь все эти полгода «отпуска» писать программы на Bash?

Т.е. если я, например, не буду разговаривать по-английски месяц, то внезапно перестану понимать англоговорящих? Вовсе нет. С башем то же самое. Я допускаю, конечно, что у других мозги могут работать иначе, но зачем тогда они себя так насилуют, занимаясь тем, что им не подходит по складу ума?

А оно, предположим, выглядит как '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see', и нет ни единого комментария.

Знакомо понятие «обфускация»? Это вот оно и есть. Этот расхожий пример сделан _специально_, чтобы было непонятно. Никто для себя, даже в случае однострочника такого писать не будет. В принципе, любой язык можно обфусцировать, но это совсем не делает все языки непонятными.

Насколько быстро ты распарсишь, что делает этот кусок?

Ну несколько минут придётся подумать, да, если не знать, что это за баян.

Твой комплекс д'Артаньяна сравнится разве что с Царём.

Perl не умер.
Но я всё еще жду, пока 6-ой объявят штабильным, и он поставит на место эти питоны.