bash - список последних измененных файлов

ты не ложка

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

Показывай эти проблемы. Но лучше для начала разобраться в теме.

Он удобен не как замена xml или json, не как огромный csv файл, а как интерфейс.

Как интерфейс это самое худшее, что только может быть.

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

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

Нет, зачем? Это совершенно разные вещи. Си — ЯП общего назначения, шелл — текстовый интерфейс.

Затем что они существуют в рамках одной системы и было предложено «ограничить» на уровне системы.

Я президент Соединённых Штатов.

Ты ламерок в камментах. Кстати,

Соединённых Штатов

лизать - это в крови.

Если ты не видишь, что я хорошо разбираюсь в этих темах, то это скорее ты далёк от них.

Ну да, ну да. Задача тебе поставлена выше(где ты рассказывал о «Не можешь, ибо сразу возникнут проблемы с непечатными символами») - покажешь уровень своего разбирательства.

Пусть прогибаются под типографические нормы, всем станет хорошо.

Читаем правильно: «ламеркам навроде меня станет хорошо». Только ламерки никого не интересуют. Особенно, когда начинают что-то требовать от других.

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

Ламерок, если твой «язык» не может в «типографики», это не значит, что нужно ограничивать всех. Хотя даже язык здесь ни при чём, и не можешь ты, а не язык.

Как интерфейс это самое худшее, что только может быть

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

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

т.е какой интерфейс лучше repl?

...explorer.exe ...

ща(10тке и раньше?) в адресной строке можно внутрение(да и всякое исполнимое) команды - т.е. входной парсер включает в себя входную строку cmd

;)

ps c аргументами, конвеерами и прочей con aux

Показывай эти проблемы. Но лучше для начала разобраться в теме.

Уже показал. Пробелы в неожиданных местах. Например, в начале имени файла и в конце.

Как интерфейс это самое худшее, что только может быть.

А ничего лучше до сих пор не придумали. Все остальные интерфейсы либо говно, либо постоянно меняются, либо имеют другие ограничения. А текстовый интерфейс ещё очень долго будет существовать.

Лучше научись работать с этим интерфейсом, чтобы он не казался «самым худшим».

Ты рассказывал «передать листинг файлов в другую программу» - чтения человеком здесь нет.

Почему нет? Я могу скопировать вывод одной программы и вставить его на вход другой. Могу ручками что-то поправить.

Для решения этой задачи целесообразно будет создавать особый протокол, API, единый фреймворк (dbus)? Возможно. Но ты никуда не денешься от того, что люди всё равно будут использовать простые интерфейсы. Если ты не хочешь им в этом помочь, то вредитель здесь ты.

покажешь уровень своего разбирательства

Если ты не просто получаешь удовольствие от написания «ламерок» 10 раз в одном сообщение, а тебе действительно интересна эта тема, сходи по ссылке, которую я скинул. У меня ресурс ограничен, а там человек проделал всю ту же самую работу.

Пусть прогибаются под типографические нормы, всем станет хорошо.

Читаем правильно: «ламеркам навроде меня станет хорошо».

Читаем правильно: «когда я родился, меня уронили на голову». Я, если что, не хочу никого оскорбить, просто вольная интерпретация твоего текста.

Ламерок, если твой «язык» не может в «типографики», это не значит, что нужно ограничивать всех.

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

Хотя даже язык здесь ни при чём, и не можешь ты, а не язык.

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

Тебе просто имена файлов нужно загнать в массив:

files=($(find ...))
for f in "${files[@]}"; do
  # делаешь что-то с $f
done

Уже показал. Пробелы в неожиданных местах. Например, в начале имени файла и в конце.

Чего ты там показал, ламерок? Показывай код. Или ты так и будешь как бот повторять мне «уже показал»/«пробелы в именах»?

В общем, тут похоже очередной скиловичок поплыл.

А ничего лучше до сих пор не придумали. Все остальные интерфейсы либо говно, либо постоянно меняются, либо имеют другие ограничения. А текстовый интерфейс ещё очень долго будет существовать.

Читаем правильно: «я ламерок, ничего кроме текста не знаю и не умею».

Лучше научись работать с этим интерфейсом, чтобы он не казался «самым худшим».

Именно ты не умеешь работать даже с текстом и пишешь о проблемах с «пробелы в именах», а вот у меня таких проблем нет. Не позорься, ламерок.

Почему нет?

Потому как передача от программы к программе. Я приводил пример, когда чтение человеком есть.

Могу ручками что-то поправить.

Ламерок не может ничего поправить. А те кто может поправить - они могут поправить и не в тексте, представляешь.

Для решения этой задачи целесообразно будет создавать особый протокол, API, единый фреймворк (dbus)?

Ты не имеешь представления ни о чём из перечисленного.

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

Опа, а чего так? Рассказывал «я разбираюсь, есть проблемы», тебя спросили «покажи» - и тут уже «ресурс ограниченный».

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

Читаем правильно: «когда я родился, меня уронили на голову». Я, если что, не хочу никого оскорбить, просто вольная интерпретация твоего текста.

Поплыл и начал сводить в срач. Какой скиловый ламерок.

Шелл может в типографику.

Ты опять путаешься. Если может, откуда у тебя проблемы с пробелами в именах? И да, я далее и написал, что шелл может, а не можешь ты, ламерок.

Конечно язык не при чём. Я нигде не говорил, что нужно фиксить язык.

Ты говорил что нужно «фиксить» систему, в то время как фиксить нужно тебя, а не систему.

а не писать оскорбления

когда я родился, меня уронили на голову

Ога. Совсем не спалился.

Показывай код.

Зачем? Ты не умеешь рассуждать без кода? Ты не можешь понять, что пробелы в начале и в конце имени файла могут привести к ошибкам во многих языках и программах, не только в шелле?

А ничего лучше до сих пор не придумали. Все остальные интерфейсы либо говно, либо постоянно меняются, либо имеют другие ограничения. А текстовый интерфейс ещё очень долго будет существовать.

Читаем правильно: «я ламерок, ничего кроме текста не знаю и не умею».

Читаем правильно: «когда мне что-то пишут, что мне не нравится, я это не принимаю, а оскорбляю собеседника».

Именно ты не умеешь работать даже с текстом и пишешь о проблемах с «пробелы в именах», а вот у меня таких проблем нет.

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

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

А те кто может поправить - они могут поправить и не в тексте, представляешь.

Да хоть в пейнте. Я изначально говорил о том, что «люди работают с текстом всю жизнь и логично ожидать, что программы должны им помогать в этом».

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

Для решения этой задачи целесообразно будет создавать особый протокол, API, единый фреймворк (dbus)?

Ты не имеешь представления ни о чём из перечисленного.

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

Опа, а чего так? Рассказывал «я разбираюсь, есть проблемы», тебя спросили «покажи» - и тут уже «ресурс ограниченный»… . Как может быть лень, если ты уже показал? Или ты не показал, болтун?

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

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

Поплыл и начал сводить в срач.

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

Ты опять путаешься. Если может [в типографику], откуда у тебя проблемы с пробелами в именах?

Шелл хорошо обрабатывает пробелы в именах (причём как показал опыт двух тредов, многие люди не знают как). Больше проблем может возникнуть из-за пробелов в начале и конце имени файла. Ну например, давай найдём все .txt файлы:

ls |grep '\.txt$'

Это очень короткая и выразительная конструкция. Но если файл будет называться "hello.txt " (пробел в конце), то она его не найдёт.

Ты говорил что нужно «фиксить» систему, в то время как фиксить нужно тебя, а не систему.

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

Ога. Совсем не спалился.

Тебе почему-то можно любой мой текст интерпретировать как «я ламерок» без объяснений, а мне нельзя что-то придумать про тебя, тоже без объяснений?

Ты не умеешь рассуждать без кода?

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

Мне за это «отсутствие представления» платят неплохую зарплату.

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

И я таки показал один пример

Линкуй.

найдём все .txt файлы: ls |grep ‘.txt$’

Но если файл будет называться "hello.txt " (пробел в конце), то она его не найдёт.

Это и есть пример? Да ты ещё более лсный, чем я думал. .txt *$ - это даже не проблема пробелов.

Я бы ещё понял(с учётом того, что ты эникей), если бы ты написал тот же ls | и там были бы файлы с ‘\n’(что сделало бы невозможной/сложной последующую работу в пайпе). Или for i in `ls ...` ; do do_some "$i" ; done - это. Хотя и то, и другое проблем не представляет и легко решается. Но ты прям захотел побить рекорды.

Это и есть пример? Да ты ещё более лсный, чем я думал. .txt *$ - это даже не проблема пробелов.

Пример: «пробелы в начале и в конце имени файла могут привести к ошибкам во многих языках и программах». А это один случай из многих, который пришёл мне на ум намного позже. Только я не просил его решить, да и решение это хреновое. В хорошо спроектированной системе простые вещи должны быть простыми, а очевидный простой способ делать простые общие задачи должен быть также правильным способом. \.txt$ не проходит этот тест и твоё знание регулярных выражений и твоя гордость не исправят эту проблему.

ты эникей

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

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

Шелл это не хорошо спроектированная система, о чём я сразу сказал. И на будущее тебе: подход «очевидный путь» не особо часто работает в скриптухах(а тем более в шелле).

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

А так, все просто юзают обходные пути: for i in * ; do ... "$i" ; done / for i in * ; do echo -ne "$i\0" ; done | ... / ls --zero ... и не имеют проблем. И никакие имена ограничивать не надо.

Эникейщик здесь ты

Нет, и свидетельства тому выше.

разрешённые символы хорошо бы ограничить

Предлагаю ввести список разрешённых имён файлов. Это точно решит все проблемы.

Шелл это не хорошо спроектированная система, о чём я сразу сказал

Шелл здесь вообще не при чём. Ядро примера — регулярное выражение. Ты (или твой коллега) мог бы написать аналогичный код на джаве.

подход «очевидный путь» не особо часто работает в скриптухах(а тем более в шелле).

Мы как бы в курсе, ведь мой пример как раз демонстрирует это.

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

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

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

Во-вторых, эта идея многим пришла в голову. Посмотри здесь секцию «Some other opinions».

А так, все просто юзают обходные пути

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

Встроенная поддержка \0 — это лучше, чем ничего. Но оно значительно усложняет скрипты, опции неоднородны (-0, -z –null, -print0), не все стандартизированы, bash всё равно обрабатывает сишные строки излишне неочевидным образом, и всё это заставляет выбирать более сложные средства там, где простых было бы достаточно. Чел попросил вывести топ-5 файлов, а ему сломали мозг.

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

Да. Ограничить имена файлов случаями: [:digit:], [:digit:]_fsm, [:digit:]_vm и ещё дополнительно разрешить имена: pg_filenode.map, pg_internal.init, PG_VERSION. Кому и зачем могут понадобиться другие имена файлов – решительно не понимаю.

«Мы просим ограничить алфавит. А нас просят отказаться от работы с чистым текстом.»

Шелл здесь вообще не при чём. Ядро примера — регулярное выражение.

Ты там поехал что-ли? Никакие регулярные выражения к именам файлов(о которых ты кукарекал) не относятся.

Ядро примера - эникейский сказочник, который теряется на конкретике.

Мы как бы в курсе, ведь мой пример как раз демонстрирует это.

Ты не в курсе. Иначе не имел бы проблем с этим и не надеялся бы на какой-то «очевидный способ». Ты опять путаешься в показаниях, лсный болтун.

Нередко это невозможно.

Да, ты когда эникеил, много узнал о том, что возможно, а что нет.

Но оно значительно усложняет скрипты, опции неоднородны (-0, -z –null, -print0), не все стандартизированы, bash всё равно обрабатывает сишные строки излишне неочевидным образом, и всё это заставляет выбирать более сложные средства там, где простых было бы достаточно.

Пошли типичные эникейские сказки в попытках оправдать свою некомпетентность.

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

Ещё и грубишь не по делу. Я говорю «привет мир», ты отвечаешь «привет гандон».

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

Это, например, в каких?

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

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

Далее я сделал этот листинг на «чистом» баше:

for i in * ; do echo -ne "$i\0" ; done | ...

И на корутилс биндингах для баша:

ls --zero ... | ...

Опущено.

гандон

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

ls |grep '\.txt$'

Аналогичный код можно написать на любом ЯП, даже если у тебя объекты вместо списка. Условный endswith(«.txt»).

Могу предположить, что одна из причин, по которой это не такая распространённая проблема — Windows запрещает так делать (ставить пробел в конце).

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

Далее я сделал этот листинг на «чистом» баше:

Вот это ты вспомнил. То, на что ты ответил, было написано примерно пять сообщений назад. И да, я тоже могу «решить» эту проблему тупо закодировав всё в json. Но я имел ввиду простой текст.

Опущено.

Закрашу 17 июля в календаре как чёрный день в моей жизни.

Эникей пытается байтить модеров затереть его позор.

И кто здесь «сказочник»?)

Ещё можно букву «Р» из алфавита выкинуть. А то картавым неудобно. В отличие от борьбы с пробелами моё предложение хотя бы продиктовано человеколюбием, а не стремлением ублажать машины.

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

Аналогичный код можно написать на любом ЯП

Нельзя. Здесь у вас абстракция протекает. А

Условный endswith(«.txt»).

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

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

Например, ограничить использование баша. Впрочем, это и так само собой происходит.

Например, ограничить использование баша

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

Это вообще совершенно разный класс проблем.

Чет я не понял. Ну тогда так:

# sh
ls |grep '\.txt$'

# pseudocode
files().map(f, f.matches('\.txt$'))

Обе проблемы возникли из-за слишком либеральной типографики, которая разрешает название "hello.txt " (пробел на конце).

И при d " while безсмысленен.

Чего? Поведение при -d " и -d $'\0' одинаковое. Я явно указываю ноль, для меня это очевиднее. Предложенный вами readarray, в общем случае, не вариант, так как может дать OOM. На +100500 файлах работает именно find -print0 | while read -d $'\0' и при этом нужно или $REPLY или не забыть про IFS.

люди будут хотеть работать с текстом

Тот текст, с которым хотят работать люди, и поток символов в STDIN/STDOUT/STDERR — это разные вещи. Например, вы идёте вспять эволюции. Изначально люди не пользовались пробелами и писали как-то так Несмотря на то, что это обычный церковнославянский текст, написанный обычными печатными буквами, отсутствие пробелов превращает его в нечитабельную простыню. Люди хотят пользоваться пробелами в тексте, потому что это нам удобно. А та штука, которую пробелы делают неудобный, очевидно нетекст для нелюдей.

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

Мы не против. Но представь себе каталог, в котором 20 файлов с названиями чисто из пробелов, разная только длина. Так ли люди хотят использовать пробелы? Так ли люди представляют себе письменность?

Пробел в конце файла и неожиданный перевод строки — из той же басни.

files().map(f, f.matches('\.txt$'))

Программа сделала ровно то, что человек у неё попросил. То, что человек попросил не то, что ему на самом деле нужно, совершенно не проблема технологии. С тем же успехом можно атаковать расширения файлов, если он нечаянно вместо '\.txt$' наберёт '\.mp3$'.

Не то с bash’ем. У него проблема возникает не на этапе f.matches(), а на этапе files().map и это уже совершенно другой класс ошибок.

Мы не против.

Есть кино такое «Зелёный слоник». Очень рекомендую посмотреть.

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

А это уже обсуждалось чуть выше.

Программа сделала ровно то, что человек у неё попросил.

Человек посмотрел на список файлов и не увидел, что один из них заканчивается на пробел. Если программа умная, она могла бы подсветить этот пробел, написать hello.txt' '. Но это не идеальное решение. ' ' — это кавычка пробел кавычка или пробел? А если пользователь хочет скопировать этот путь? А если он сделает скриншот и другой пользователь скопирует этот путь с картинки? А если в директории уже есть файл, который называется hello.txt' ' (на конце кавычка пробел кавычка)? Почему вообще мы должны считать сложновычислимый текст полезнее простого?

Типографика и здравый смысл неизбежны.

С тем же успехом можно атаковать расширения файлов, если он нечаянно вместо ‘.txt$’ наберёт ‘.mp3$’.

Нет, это уже другое. Пробел можно случайно добавить во время редактирования текста (особенно автоматического). И ты его не увидишь. Ты можешь вообще не знать содержимое директории. А если возникнет ошибка, связанная с txt vs mp3, то она быстро даст о себе знать.

Здесь более близким примером было бы сравнение русской ‘с’ с английской ‘c’.

Edit: ещё одна вещь:

Программа сделала ровно то, что человек у неё попросил.

Это не единственный подход к созданию систем. Например, мнение Линуса про дизайн файловых систем:

“...filesystem people should aim to make “badly written” code “just work” unless people are really really unlucky. Because like it or not, that’s what 99% of all code is... Crying that it’s an application bug is like crying over the speed of light: you should deal with *reality*, not what you wish reality was.”

Чего? Поведение при -d " и -d $'\0' одинаковое.

Странно, как вы это поняли обратное, ведь я такого не говорил.

Предложенный вами readarray, в общем случае, не вариант, так как может дать OOM.

Программы, закладывающиеся на работу в обход OOM пишутся уж явно не на скриптовых языках и не простыми методами. А то так можно дойти до того, что массивы вообще использовать нигде и никогда нельзя. Для меня это очевидно, как и то, что получение промежуточных результатов в виде массива - это удобное средство для расширения ТЗ, ведь тот же find вам не отсортирует, а ls сортирует только внутри каждого каталога отдельно.

файлах работает именно find -print0 | while

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

в обход OOM пишутся уж явно не на скриптовых языках

Да какая там разница, скрипт может просто что-то подсчитывать из потока имён файлов, отдаваемых find, а может вобще ls -f. И обрабатывать, допустим, всю файлопомойку от корня. А до OOM на каком-нибудь одноплатнике с 512 Мб ОЗУ совсем не далеко. Особенно, если имена с пробелами, там постоянно допустимой длины имени файла не хватает.

Пишу больше для ТС'а, чтобы он понимал, что массив bash хранит в ОЗУ, и ещё, поди, с неплохим оверхедом.

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

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

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

Но это и проблема языков тоже. Что теперь делать со скриптами, которые используют \.txt$? Сделать \.txt *$? А может \.txt[\x09-\x0d\x20]*$? Или \.txt[\x09-\x0d\x20\xa0\x202f]*$'? Или hasextension("txt")?

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

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

Смотря как посмотреть. Эту проблему тоже можно раздробить на две.

Одна проблема — это чтение списка строк. В баше эта вещь сломана, в других шеллах — всё норм.

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

сочленена в https://duckdb.org/docs/stable/clients/cli/overview.html#reading-from-stdin-a...

есть одна cli : duckdb

её можно в конвеере для sql фильтрации; оверхеда (вышеупомянутого oom падме хум избегно)

cat test.csv | duckdb -c "SELECT * FROM read_csv('/dev/stdin')"

т.е ls - ключи вытаШИТь нужную инфу а процессинг общеизвестным sql-кляузением с выхлопом в любом журнальном формате али по своим фломастерам вкусу

за изысками см:

https://duckdb.org/docs/stable/clients/cli/overview.html#non-interactive-usage

https://tldr.inbrowser.app/pages/common/duckdb