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

Вы атакуете нормальную технологию «разделять слова пробелами»

Тут вы не договариваете. При нормальном разделении слов пробелами смысл не меняется от числа пробелов. И смысл не меняется пробелы или табуляции, \r или \n. Всякие diff и прочие средства обработки текстов спокойно игнорируют лишие пробелы. А у файлов это не так, технология нарушается.

если использовать нормальные инструменты

Я с этого и начал. Что отказываться надо не от bash, а от всей существюущей командной строки. Не от самой идеи, а от существующих утилит.

а что исторически сложившаяся гора костылей.

«Стройная система костылей и подпорок» (C). И в этой системе лучше просто не использовать пробелы и прочее в именах файлов, чем потом разбираться с возникшими сложностями. Отказ только от bash ничего не поменяет.

При нормальном разделении слов пробелами смысл не меняется от числа пробелов.

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

Я с этого и начал. Что отказываться надо не от bash, а от всей существюущей командной строки. Не от самой идеи, а от существующих утилит.

Занятно, что я тоже, заговорив о владыке и повелителе нашем.

Вот, прямо как в этом тексте. И в вашем тоже.

Я не могу посмотреть какой текст вы набирали, я не админ этого форума/сайта. Да и вы, надеюсь, тоже не имеет доступа к БД, чтобы видеть сколько пробелов я ставлю в исходном сообщении. Движок форума выкидывает лишние пробелы и т.д. Это надо просить кого-то прямыми запросами к БД посчитать сколько сообщений, где встречается два пробела. Но не так важно, сколько раз ЛОР не показывал чей-то текст, который был набран через два пробела, важно, что движок ограничивает, но это всех устраивает. А имена файлов никто не ограничивает по числу подряд идущих пробелов. И с такими именами, где-нибудь, внутри какой-нибудь библиотеки/встроенной функцией ЯП может вылезти бяка, что подряд идущие пробелы могут быть превращены в один.

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

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

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

Но как-то программисты давали имена переменным без пробелов, потом CamelCase подвезли. В именах файлов можно использовать подчёркивание, можно использовать nbsp (\u00A0) и это не создаст проблем bash'у. Но все хоят и обычный пробел (\u0020) и скрипт на bash. И тут пусть каждый сам решает, от чего ему проще отказаться, от (\u0020) в именах файлов или от скриптов на bash.

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

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

то табуляции, переводы строк и прочие нечитаемые символы

Вы зачем-то вынесли на обуждение какую-то дичь и героически с нею боретесь.

Но как-то программисты давали имена переменным без пробелов

А древние иудеи (может и современные тоже?) выкидывали гласные из слов. И тоже как-то жили. Их, впрочем, постоянно завоевывали, порабощали и всячески тиранили окрестные народы, но не думаю, что это связано.

в бэш с сортировкой файлов по произвольному атрибуту все плохо (по сравнению с другими языками)

как бы вы сделали?

выбрал бы что-нибудь другое

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

Это Вам поможет inotifywait

И тут пусть каждый сам решает, от чего ему проще отказаться, от (\u0020) в именах файлов или от скриптов на bash.

А может вы просто не желаете видеть, что bash не понимаете? Ведь именно не для *sh*, а для людей придумано, что $* $@ «$*» «$@» - это 4 разных поведения, специально сделанных и вовсе не громоздких конструкций, которые как раз решают желаемые варианты ТЗ, нужно только один раз проработать знание языка.

Не пишите толстовскими предложениями, а то смысл к концу предложения теряется. Понимать bash невозможно, это не Fortran или C. Увероваших, что они знаю bash я видел много, но через какое-то время они совершали очередное открытие.

Но дело не только в bash, а во всём зоопарке команд командной строки. Одинаковое имя со спецсимволами команды ls, find и printf «%q» выведут по разному. Такие имена неудобно не только обрабатывать в bash, но и копи-пастить. Эта ветка, в которую вы начали что-то писать про ТЗ, совсем не про конкретный скрипт.

Эта ветка, в которую вы начали что-то писать про ТЗ

Я написал, что пробелы - это «красота» для людей, скорее не имеющих программистских привычек. Но в *sh* у всех есть инструмент как делать без затрат на навороты решение исходной задачи, где есть пробелы в файлах или где по быстрому надо сделать наколенный скрипт с обработкой файлов без пробелов с удобным IFS с пробельными символами. Ну а насчёт ls — давно надо понять, что эта утилита ну уж совсем для примитивных скриптов, так как она слишком человечная, доказательство, кстати, очень элементарное, в ней опция zero-term появилась очень недавно.

Здесь речь уже не только о скриптах. Пробелы и прочие «неправильные» символы в именах файлов вызывают проблемы или лишние телодвижения и при копи-пасте из выхлопа в консоли куда-нибудь в текстовый редактор (конфиг или исходный код программы) и в обратном направлении.

без затрат на навороты

В bash всегда есть нюансы, например, тот же всем любимый read маньячно режет хвостовые пробелы, даже если разделитель $'\0', и нужно использовать $REPLY.

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

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

$REPLY

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

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

Вывести в простом формате «Файл - дата изменения».
*.md
3. как бы вы сделали?

$ cat lsn.cpp

// https://www.linux.org.ru/forum/general/18024116
// g++ -std=c++23 lsn.cpp -o lsn

#include <filesystem>
#include <algorithm>
#include <chrono>
#include <ranges>
#include <vector>
#include <print>

int main ()
{
    using namespace std::filesystem;
    using namespace std::ranges;
    using namespace std::views;

    constexpr auto N = 10;

//    auto match_file = [](const auto& n) { return n.is_regular_file(); };
    auto match_md = [](const auto& n) { return n.is_regular_file() && n.path().extension() == ".md"; };
    auto print = [](const auto& n) { std::println("{} - {}", n.path().string(), n.last_write_time()); };

    auto files = to<std::vector>(filter(recursive_directory_iterator(current_path(), directory_options::skip_permission_denied), match_md));
    sort(files, [](const auto& a, const auto& b) { return a.last_write_time() > b.last_write_time(); });
    for_each(take(files, N), print);
}

«одна ошибка и ты ошибся»

Ошибка она и в Африке ошибка.

количество деталей за которыми должен следить программист

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

Кого интересуют гнилые отмазки? Главное результат: bash излишне нагружает память и внимательность программиста

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

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

3. как бы вы сделали?

❯ fselect path, modified from "Spaced folder" where name = "*.md" order by modified desc into csv

Spaced sub folder/Sub File 3.md,2025-07-16 15:35:11
Spaced sub folder/Sub File 2.md,2025-07-16 15:35:08
Spaced sub folder/Sub File 1.md,2025-07-16 15:35:06
File 3.md,2025-07-16 15:24:19
File 2.md,2025-07-16 15:24:18
File 1.md,2025-07-16 15:24:15

Выглядит как «а ещё я крестиком вышивать умею». Коллеги вам за такое много «лучей любви» посылать будут. Ну а самое главное - если уж «угорать» то держать heap из последних N модифицированных файлов и обновлять по мере чтения директорий, а не вот это вот…

Я же написал, свойства не у этой переменной, а у read :

маньячно режет хвостовые пробелы

Вот для сравнения:

[/tmp]$ printf "123  \0" | while read -d $'\0' A; do echo "'$A'"; done
'123'
[/tmp]$ printf "123  \0" | while read -d $'\0'; do echo "'$REPLY'"; done
'123  '

То есть, даже с разделителем '\0' пробелы обрезаются. Как без знания про REPLY через read получить все введённые хвостовые пробелы?

Это пример «лукавства» bash. readarray не режет хвостовые пробелы, а read режет. Схожие конструкции имеют разное поведение.

Как уже правильно сформулировали, bash избыточно нагружает память. ИМХО, лучше сложное на bash не писать. Как уже писал, что не раз видел, что человек, считающий себя программистом и считающий, что знает bash, оказывается в ситуации, когда он не понимает, почему его bash-скрипт отработал не так, как хотелось. Но это ваше право считать, что на bash+«утилиты командной строки» обработка пробелов '0x20' не является сложным.

человек, считающий себя программистом и считающий, что знает bash

ошибается.

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

А рассматриваемые примеры… Это интересно, конечно. Но на самом деле смысл не в том как решить сложную ситуацию. Смысл в том, как не допустить такой ситуации.

Ладно 's/человек, считающий себя программистом/человек, работающий программистом/' и пишет он не только на bash.

Смысл в том, как не допустить такой ситуации.

Лучше уточните, какой именно «такой» ситуации, а то в этом топике разные точки зрения.

Человек считающий bash языком программирования

А это уже попахивает разжиганием холивара :) «bash — не ЯП», «bash-скрпты — не программы», «если программист написал хоть один bash-скрипт — вон из профессии»...

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

Вообще, на мой взгляд 8.3 хватит всем. Посмотри, например ты пользуешься википедией. И скорее всего ничего не знаешь о её файлах. А СУБД использует что то очень близкое к 8.3.

Люди имеют дело с файлами от безысходности. Но потакать размещению краткой аннотации в названии всё же не следует.

А bash это конечно не язык программирования. Но программы на нём писать можно. Но очень простые.

8.3 хватит всем

Почему «8.3», а не int?

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

Которая к файлам никакого отношения не имеет. Там и «0.0» хватит.

Люди имеют дело с файлами от безысходности

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

Но вообще да, там где есть возможность использовать более подходящую организацию данных, файлами(для структурирования) не пользуются.

Но потакать размещению краткой аннотации в названии всё же не следует.

Название и есть краткая аннотация, не? Иначе тебе «8.3» был бы не нужен, хватило бы int’ов.

Можно и больше 8. Но разрешённые символы хорошо бы ограничить например как у доменных имён.

А в текущих реалиях, хотя бы не злоупотре#@&…

Но разрешённые символы хорошо бы ограничить например как у доменных имён.

Не думаю, что стоит. Шелл-проблемы и есть шелл-проблемы. Ограничивать ради этого имена - примерно тот же путь, что и использовать файлы для структурирования - всё ради того, чтобы шелл(или ещё что-то простенькое) смогло обработать эти данные. Как и в целом подстройка с запретами под наименее мощное средство.

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

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

Эти запреты прекрасно видно в дискуссиях про шелл. Опытные пользователи просят не разбивать текст на линии — простейшая и полезнейшая операция при работе со строками.

шелл(или ещё что-то простенькое) … наименее мощное средство.

Это шелл простенький и немощный? Мы точно находимся на сайте про юникс-подобную ОС или здесь explorer.exe считается мощнее /bin/sh?

Лучше наоборот пусть люди прогибаются под шелл.

Но если говорить более нейтрально, то важны два принципа:

1. Разговаривай на языке, который понимаешь. It would be absurd if I suddenly switch to English. Также и программы нужно делать такими, чтобы они могли легко взаимодействовать друг с другом, чтобы было меньше лишних телодвижений. Разбивка текста на линии — это как раз тот язык, который программы с текстовым интерфейсом очень хорошо понимают. От него нет смысла отказываться, even if you really really really want it. Similarly, нет никакого смысла начинать с попытки делать абсолютно всё что угодно, а потом пытаться причесать это для удобной работы. Это невозможно.

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

Tl;dr: просто потому что explorer.exe и языки общего назначения терпят плохую типографику в именах файлов, не обозначает, что это единственный или самый лучший подход.

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

Мы просим просто ограничить алфавит.

Это звучит авторитарно, но это не так.

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

Основной кандидат — это перевод строки.

Кстати, на самом деле этот параграф относится к предыдущему предложению («Основной …»), просто я добавил перевод строки. У меня такой стиль.

\n как escape sequence типографически недружелюбен. Ни программа, ни человек не могут его просто прочесть. Что если там будет не \n, а ‘\n’? Покрыть все частные случаи — это очень хрупкая задача, сделать это системно — невозможно.

Другие непечатные символы — не знаю.

Я только что нашёл подробное исследование этих проблем. Очень много деталей и примеров.

подробное исследование

Всем заинтересованным: можно сразу перейти в секцию “It works!”

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

Могу. Причём даже из шелла, не говоря уже о чём-то более мощном.

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

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

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

Текст - самый неудобный формат. Никакие кейсы он не покрывает. Единственный кейс текста - немощность инструментария/человека за этим инструментарием.

Это шелл простенький и немощный?

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

Лучше наоборот пусть люди прогибаются под шелл.

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

Это не столько шелл-проблемы, сколько типографические проблемы.

Это проблемы выч. техники в текущем виде. Посмотри на гарвардскую архитектуру. Инструкции и данные в разной памяти. Какие проблемы сходу исчезают? Но это на всех уровнях. Если мы отделим инструкции то избавимся от некоторых проблем. Но останется вопрос структурирования информации в котором также много интересного.

В конечном счёте ты упрёшься в вопрос а что такое информация. Ты говоришь про текст. Но текст это только дамп. А думаешь ты структурами.

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

bash (см A-Z Programming Language набор интерьвью)

малоудобен для углублённой манипуляции атрибутами файлов

поэтому тут и awk и sed и даже perl ....

спотыкание на пробелах очевидно ибо в текстовых процесорах - а консоль баша и есть язык преобразований строк - строки есть единственный первокласнный тип поэтому и синтаксис любая не пробельная(и без скобок языка ) последовательность символов это строка

и только $префикс делает строку именем али постфикс сообщающий что это функции_имя(

поэтому ipython уже (на таких задачах) актуален

так то и на sed'е ассемблер реализуем

отделение кода от данных делает не возможным компиляцию из сырца(данные) в код

т.е. существование гарвардской архитектуры лишь указание что данные от кода в ней не абсолютно отделены :)

fat-12

поэтому повсеместность кратностей-12

1 байт атрибута 3 байта расширение(«тип») остальное knowname

Понимание что такое информация и как с ней работать делает не нужной компиляцию.

Как без знания про REPLY через read получить все введённые хвостовые пробелы?

Фигасе! Похоже на баг.

как отчуждать понимание?

ибо код и есть отчуждение

Не, это не баг, это фича. На самом деле режутся хвостовые $IFS, то есть выставить IFS=$'\0'.

If there are more words than names, the remaining words and their intervening delimiters are assigned to the last name.

Но вот это предожение в man bash многие пропускают. Не очевидное поведение, когда IFS внутри строки будет записано в переменную, а хвостовые нет. И каких-то версиях bash, вроде, были проблемы с IFS=$'\0', поэтому вылезло решение с REPLY, но может я путаю.

Почему телефон не высаживает батарею проигрывая mp3?

И, да, отчуждение – зло.

То есть, даже с разделителем '\0' пробелы обрезаются. Как без знания про REPLY через read получить все введённые хвостовые пробелы?

printf "123 \0" | ( IFS= read -d '' A; echo "'$A'" )

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

Это пример «лукавства» bash

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

т.е копуляторы тока за фасадом порталов?

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

Что за фасадом лисп машины?

А ты вообще написан на языке с алфавитом из четырёх знаков.

Sexp - но там как раз даныекод коданые кодоны

неа - проф.Савельев(троль и не только) сообщил окружающим что при билдинге важную роль играют механические обстоятельства - т.е. интерпритирующая система завязана на 1/137 и прочие выпавшие комбинации нумерующие наш универсум

и всё таки как на гарвардах компилируют?

g механозависимых нарушениях

Могу. Причём даже из шелла, не говоря уже о чём-то более мощном.

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

Текст - самый неудобный формат.

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

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

Если бы он никакие кейсы не покрывал, то программы с командным/текстовым интерфейсом не дожили до наших дней.

Ты хочешь посравнивать с сишкой?

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

Ты админ какой-то или в этом роде? Зачем тогда рассуждаешь на темы, далёкие от тебя?

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

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

Ты хотел сказать, [пусть люди прогибаются под] под немощных ламерков, навроде тебя?

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

Почитай это исследование, может чему-нибудь научишься.

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

+ к созданию причастна инкубатор если сурогатная

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

поэтому вылезло решение с REPLY

Вроде бы это просто переменная по умолчанию, если не задана своя, а тут получается у неё какая-то фича и даже решение, — какой-то вынос мозга 😁

Что такое информация?

какая-то фича и даже решение, — какой-то вынос мозга

Здесь так принято. Удивительно, что всё это при этом как-то (и неплохо) работает. Не то чтоб прямо убеждает, что worse is better, но worse is kind of OK too.

не всякий «типографски» однозначный текст

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

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

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

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

так то реально 640кб хватит всем до сих пор актуально - но память и время вычислителей дешевеет быстрее чем тупеют(не только сами) оконечные биочасти киборгов