Опубликован выпуск проекта uutils coreutils 0.4.0 (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64214
>работать на платформах Windows, Redox и FuchsiaА зачем это на винде?
более того... зачем оно вообще ?
> показывает размеры каждого каталога с вычетом вложенных каталогов, из-за чего их размер получается меньше фактическогоУчитывая, что ещё и работает неправильно.
Это GNUтая версия показывает неправильно)))
Ты чем читал?В uutils: total # больше фактического
> Ты чем читал?
> В uutils: total # больше фактическогоGNU Utils
>> 33955 /var # меньше фактического
-s, --summarize
display only a total for each argument
-c, --total
produce a grand totalНу и бсдшный du :
du -smc /var/log /var
7 /var/log
939 /var
945 totaldu -smc /var /var/log
939 /var
7 /var/log
945 total
# гнутый du
gdu -smc /var/log /var
7 /var/log
932 /var
939 totalgdu -smc /var /var/log
939 /var
939 total
а так - все хорошо, прекрасная маркиза!
Почему у раста сумма двух чисел не равна их сумме?
> Почему у раста сумма двух чисел не равна их сумме?Где ты в бсдшном du нашел раст?
И да, спецом для тебя:
-m Display block counts in 1048576-byte (1 MiB) blocks.
Если сначала считать в байтах, суммировать, а потом округлить в блоки, то сумма вполне может быть != округлять в блоки и считать сумму.
> 37034 total # больше фактического, но соответствует суммено НЕ соответствует сумме, т.к. растманы не умеют складывать числа. Пытаются оправдаться на какое-то округление блоков, пишут, что соответствует, но в реальности не соответствует, раст облажался во всём.
Числа числами, а от сумы не зарекайся.
>Почему у раста сумма двух чисел не равна их сумме?Почему раст при оценке объемов двух включающих себя друг в друге каталогов в графе общий объем не учитывает вышеописанное обстоятельство: у Даши в сумке с овощами - овощей на 10 кг из них моркови 5 кг. Сколько весит сумка? - Раст: 15 кг, а чо нет-то?? ахахах...
А зачем комментарий обрезал???))))
Ты это хотел увидеть?> соответствует сумме
НЕ соответствует. Раст: 1540 + 35495 = 37035 != 37033
> Ты это хотел увидеть?
>> соответствует сумме
> НЕ соответствует. Раст: 1540 + 35495 = 37035 != 37033Соответствует.
-m like --block-size=1MПросто ты классический Воен Супротив Раста, тебе некогда разбираться в "мелочах", тебе ведь Голактеку от Раста спасать надо! 😀
Какие блоки, при чём тут они? Раст выдал total=37034, хотя на самом деле всё занимает 35495. Чувствуешь разницу? В расте total не имеет физической основы, это попугаи, потерявшие реальность ещё до округлений.
> Какие блоки, при чём тут они? Раст выдал total=37034, хотя на самом
> деле всё занимает 35495. Чувствуешь разницу? В расте total не имеет
> физической основы, это попугаи, потерявшие реальность ещё до округлений.ЧуЙствую спрыг с неудобной темы. Но и ту уже разжевали здесь: POSIX 2018 vs 2024.
Кстати, еще раз, упомяну, что точно такое же выдаст бсдшный du, который ну вот совсем не на расте:du -smc /var/log /var
7 /var/log
942 /var
948 total
(при том что размер /var = 942)
В uutils:1540 + 35495 = 37035 != 37033!
по факту что та версия показывает неправильно что та, вопрос в том хотим мы оставить неправильно с которым свыклись и вокруг которого научились плясать или хотим пофиксить оба варанта наконец. имхо прикол с тем что гну показывает разные цифры каталогам в зависимости от порядка их указания в запросе вообще недопустимое поведение для утилиты и давно должно быть пофикшено.
GNU показывает и считает всё правильно, там в стандарте написано, что каждый элемент подсчитывается ровно один раз, в итоге сумма - верная. А в расте элементы могут несколько раз считаться, что приводит к билиберде.
А как определяется правильность? GNU и busybox показывают всё по стандарту, а нетакуси из uutils решили сделать не по стандарту, то есть, неправильно.
>А как определяется правильность?Обычно логикой и здравым смыслом. Но это у нормальных людей. У Военов Борьбы Супротив Раста - кривым стандартом.
ну здрасьте, лет 10 планомерно выкидываем гну на мороз и тут такие вопросы. Если вы не интересуетесь опенсорсом, то к чему тогда вопросы?
> более того... зачем оно вообще ?Тссс! Пусть эти господа убивают свое время на всякие редоксы, фуксии и что там еще. Реактос еще пусть не забудут. Подвалим этим гражданам работенки.
Слышал про MSYS2 или хотя бы Git for windows?
ну так там все utils собраны mingw64 зачем там что-то еще ?
В Msys2 оригинальные GNU Coreutils.
В линуксах пока что тоже в основном оригинальные coreutils, но ОП не спрашивал зачем это нужно линуксам.
>А зачем это на винде?А зачем кривой косой вечно недопереписанный линукс, если можно взять настоящую операционную систему и просто установить на нее нужные утилиты?
> А зачем кривой косой вечно недопереписанный линукс, если можно взять настоящую
> операционную систему и просто установить на нее нужные утилиты?Затем что:
1) в линухе у меня проекты билдуются - в разы быстрее. А я не маклауд тормозную ос ждать.
2) не делают мозги онлайн акаунтами, активациями, рекламой, AI в блокноте и отсылкой клавиш майкрософту для улучшения качества обслуживания.
3) в винде изначально вообще пакетногом манагера нет и установка софта VS linux это ужасный гемор, занимающий намного больше времени.
4) при попытке собрать что-то типа linux kernel винды вообще пожалуй загнутся нахрен.
5) с автоматизацией, родным тулингом и проч в винде полный кошмар, настолько что они вот в WSL вдарились и прочие msys.В общем - нормальная операционка для буха Глаши и прочих кассиров с операторами ПК. Если кто хотел взаимодействие с компом на более продвинутом уровне - УПС. Винды это сущий кошмар. И майкрософт как вендор - головняка кусок.
боюсь что даже буху Глаше винда не оченьто и подходит, иначе зачем им тп и админы которых они дергают на каждый чих.лично я не считаю винду осью вообще, как была оболочка для дос так и осталась, из коробки не умеет вообще ничего, драйвера поставь софт поставь, в чем автоматизация, если можно поставить драйвера и соыт для любого рандомного загрузчика, и он тоже будет копировать файлы...и что lilo или grub теперь тоже назвать ос
аноним даже не знаю что имел ввиду, может мак, но там же бсд приукрашенная скруглениями, может бсд, так сейчас именно она являет собой образец недописанности, который тырит драйвера из линукса..
вероятнее у автора какоето расстройство рассудка, и он считает что гдето в параллельном измерении есть одна единственная ос которая устраивает всех и пишет ее не иначе как сам боженька, без ошибок и недочетов, выкатывая релизы с фичами которые никто не просил, но они очень нужны, именно тогда когда вышли, эх если бы так было
> боюсь что даже буху Глаше винда не оченьто и подходит, иначе зачем
> им тп и админы которых они дергают на каждый чих.Вообще да, если кому-то такому вкатить убунту и отдрессировать, майнтенанса в разы меньше.
> лично я не считаю винду осью вообще, как была оболочка для дос
> так и осталась,Там уже давно нет никакого намека на DOS. Есть самобытное ядро NT. Это 2 разные мира.
> lilo или grub теперь тоже назвать ос
Можно. Но - однозадачной. А NT таки это полная честная многозадачная, многопользовательская система. С своим внутренним апи, которое даже не WinAPI так то. А поверх него можно вот делать - winapi или что там еще.
В лине так же можно сделать winapi путем использования wine.
> образец недописанности, который тырит драйвера из линукса..
Не очень понял что сие означает но то как BSD тырят дрова из линуха забавно, да. И ведь их давно предупреждали. И по линии Xorg, и по DRM/KMS. Но не, они вопили что их и так все устраивает - ничего менять не надо. А в Linux народ тот ужас совсем не устраивал вот.
> именно тогда когда вышли, эх если бы так было
Я знаю 1 рецепт. Он правда нифига не простой. Если хочется чтобы работа была сделана качественно - придется сделать ее самому. А если даже и не получится, свое то все равно - не пахнет.
> Можно. Но - однозадачной. А NT таки это полная честная многозадачнаяВ целом вопросов нет, напильником прикрутить можно всё, но виндовым плюсом было то, что работает из каробки без лишних телодвижений, племяш тут решил поставить вин11, ох блин, а я хз че куда кого, теперь там терминал надо открывать какието команды вводить, чтобы оно локальные учетки использовало, как по мне федору проще поставить, при том что у федоры инет условно есть, так как драйвера сетевух есть, а вот у винды нет. И речь именно о том, что федора работает после инсталяции, хочешь офис запустит, хочешь на принтер напечатает, а в винде, ты пыжишься ставишь ее, потом удаляешь всякое ненужное аля иксбокс-чего-то-там, потом ставишь нужное, и на выходе получаешь просто винду с тупняками, которая ни рейды ни вланы знать не знает..вот и получается что это оболочка, которую еще надо наполнить содержимым.
> Там уже давно нет никакого намека на DOS.
Однако, как мы помним, со времен доса винда блюдет совместимость, и 866 кодировка там присутствует, на ряду с 1251, и юникодом, при этом тузл посмотреть ip с новыми кодировками так и не завезли, и ipconfig выдает 866 страницу которую фиг прочитаешь потом в блокноте. Вот и получается, оболочкой была, оболочкой и осталась, это она в микрософт шлет отчеты, со всем чем можно, а админу той шараги страдать.
> И по линии Xorg, и по DRM/KMS. Но не, они вопили что их и так все устраивает
Ага, а еще ifconfig для настройки сетевух, с его легаси из 1980, чтобы создавать алиас к сетевке и вешать туда второй адрес, так как 2 на устройство мы не умеем и нам оно не надо, в общем в начале 2000 было понятно что ребятам прямая дорога на свалку истории.
> Я знаю 1 рецепт. Он правда нифига не простой. Если хочется чтобы работа была сделана качественно - придется сделать ее самому. А если даже и не получится, свое то все равно - не пахнет.
Ну такое, часто бывает, что хороших решений просто нет, - вот отличный пример, всевозможные магазины приложений, типа они там сами все делают, с разраба только код, и не надо зависимостей, опакечиваний, сайтов для распространения, жмяк кнопочку, и там оно само, а потом пришли абюзеры, взломали разраба, напихали троянов, и теперь 100500 факторные авторизации, пароли по политики, ключи и смски, а потом еще ждите модерации, а то вдруг чего. Смеялись когдато, над шуткой про яд в солонку в кафешке, а ведь это по сути оно и есть.
И решить эту проблему просто нельзя. Либо вечно багованный тестинг в котором каждый день новые проблемы, либо супер стабильный дебиан в котором нималейшего шанса на исправление старых.
1) Результаты тестирования ты, конечно, не приведёшь. Потому что ну как можно не верить джентльменам, да?
2) Отключаемо.
3) Изначально - нет, но установить, например, тот же choco никто не запрещает. И ставь себе потом, что хочешь из их репозитария (в нём есть очень многое) одной командой choco install.
4) И снова бездоказательное высказывание.
5) Powershell умеет всё, и гораздо лучше всяких поделок, типа bash, ksh и прочего подобного. Это на уровне локального хоста. А на уровне предприятия есть Active Directory - готовое решение для автоматизации администрирования масштаба предприятия. У Линукса такого и близко нет.
Навскидку: https://habr.com/ru/news/962756/
Упс, как же так? Это же НАСТОЯЩАЯ ОС!
Индусский Интеллект. Каждая версия хуже предыдущей (с приходом Наделлы к рублю компании). Недавно хвастались что 30 процентов схалтурили и с генеративным ИИ
Ничего себе какое открытие! В сложном программном обеспечении есть баги. Вот это да! То, что некоторые дыры безопасности не фиксятся годами в Линуксе - это, конечно, сущий пустячок. Также вспоминается скандал, когда тролли решили намеренно добавить бекдор в код ядра, и "тысяча глаз" не заметила ничего.
> "тысяча глаз" не заметила ничего.А откуда ты про это узнал? Ты 1001 пара глаз? ;)
А сколько по-твоему? Это ж цельный код цельного ядра, итить его!
можно взять freebsd так то да
>Дополнительно можно отметить расхождение в поведении утилиты "du" из наборов uutils и GNU Coreutils, всплывшее после перехода Ubuntu 25.10 на uutils. Разработчики ещё не решили трактовать ли данное расхождение как ошибку, так как с одной стороны в поведении uutils есть логика и тестовый набор GNU Coreutils не выявляет проблемПроблема в том, что переписанные тесты переписаны также качественно, как и все остальное. Почему язык, который должен был облегчить программирование только усложнил его?
Не совсем понятно как это чудовище вообще могло что-то облегчить
>Не совсем понятно как это чудовище вообще могло что-то облегчитьРаст-то? Пыталось мой желудок, когда я синтаксис увидел.
Неосиляторы как всегда ругают синтаксис
Терпишь?
Трудно жить с руками из плеч?
Так это GNUтые тесты такие, а не uutils)))
Это отблески грядущего
Э! Тесты же ж от пакета GNU Coreutil используются - никто их вроде бы на rust переписывать не собирался. Вот что по ходу могут правочки появиться - это да - но на стороне _тестов_ (Читай - GNU) а не уот тут уот.
Мне казалось, что шутки про весь мир неподходящий для Rust всего лишь шутки...
Новость-не-читай-комментарий-оставляй? Тест - GNU'тый - ПРОХОДИТСЯ.
Тесты проходят, а программа правильно не работает. Чудеса.
> Тесты проходят, а программа правильно не работает. Чудеса.Ну-ну.
# гну
gdu -smc /var/log /var
7 /var/log
935 /var
942 totalbusybox du -smc /var/log /var
7 /var/log
935 /var
941 total# бсд
du -smc /var/log /var
7 /var/log
942 /var
948 total# uutils
uu-du -smc /var/log /var
7 /var/log
942 /var
948 total
Ну это легко объяснимо. Видите ли, POSIX не стоит на месте.Так, например, в стандарте POSIX.1-2018, написано[1]:
> A file that occurs multiple times under one file operand and that has a link count greater than 1 shall be counted and written for only one entry. It is implementation-defined whether a file that has a link count no greater than 1 is counted and written just once, or is counted and written for each occurrence. It is implementation-defined whether a file that occurs under one file operand is counted for other file operands.
А вот в стандарте POSIX.1-2024, на который я ссылался ранее[2], написано следующее:
> A file that occurs multiple times shall be counted and written for only one entry, even if the occurrences are under different file operands.
Так что BSD du удовлетворяет стандарту 2018го года, а GNU du -- более свежему стандарту 2024го года.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/d...
[2] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/d...
> Так что BSD du удовлетворяет стандарту 2018го года, а GNU du --
> более свежему стандарту 2024го года.Я бы сильно удивился, если бы du из 13 фряхи удовлетворял 😉:
ll /usr/bin/du
-r-xr-xr-x 1 root wheel 13K 21 Nov. 2022 /usr/bin/du*
> ll /usr/bin/du
> -r-xr-xr-x 1 root wheel 13K 21 Nov. 2022 /usr/bin/du*Ну вот видите, ларчик-то просто открывался. =)
Я вот из интереса смотрел на du из базовой поставки MacOS -- там точно такая же ситуация.
Интересно было бы узнать, это BSD-шники свой du давно не обновляли, или Apple просто редко утягивает актуальные версии?
>> Так что BSD du удовлетворяет стандарту 2018го года, а GNU du -- более свежему стандарту 2024го года.
> Я бы сильно удивился, если бы du из 13 фряхи удовлетворялЗагрузился в ВМ с имиджем FreeBSD-15.0-Beta5 [1]: du в нём ведёт себя так же, как и в 13й версии, соответствия POSIX.1-2024 не наблюдается.
[1] https://download.freebsd.org/releases/VM-IMAGES/15.0-BETA5/
> Так что BSD du удовлетворяет стандарту 2018го года, а GNU du --
> более свежему стандарту 2024го года.Кстати, забавно было бы посмотреть, когда это появилось у GNU. В смысле это GNU под "POSIX"-требования подстроились, или наоборот - POSIX обвели мелом воронку и написали, что "бомба СНОВА попала в эпицентр!"?
>> Так что BSD du удовлетворяет стандарту 2018го года, а GNU du -- более свежему стандарту 2024го года.
> Кстати, забавно было бы посмотреть, когда это появилось у GNU. В смысле это GNU под "POSIX"-требования подстроились, или наоборотВ разных случаях может быть по-разному.
Лично я буквально вчера смотрел на info tsort[1], и там было чётко написано:
> To conform to POSIX.1-2024, tsort accepts and ignores the option -w.
И это наглядный пример того, что в GNU Coreutils делают доработки ради POSIX compliance.
Конкретно про ситуацию с поведением du -- не могу сказать. Тут надо покопать, а у меня нет на то желания.
[1] https://www.gnu.org/software/coreutils/manual/html_node/tsor...
# бсд
# uutilsНу так логично же.
uutils ориентировались на свободные бсдшные утилиты, а не на гнурак.
А busybox тоже под жпл, поэтому списывали они с gnu утилит.
> Cross-platform Rust rewrite of the GNU coreutilsчитать до просветления
Ну так все вопросы к сишникам, что такие кривые тесты написали.
Опять сишники в штаны Расту ... Надо же было умудриться, что у раста total не соответствует ни фактически занимаемому месту, ни сумме элементов из-за округлений при целочисленном сложении.
> Опять сишники в штаны РастуА в чем ирония, что сишники не умеют писать тесты? А причем тогда тут раст?
Растройхетеры опять просчитались, но где?
Где-то тут:В uutils: ... total # больше фактического
причём НЕ соответствует сумме. Растманы объясняют ошибку целочисленного сложения "округлением".
Опять для хайпу сделали ашипку - про них поговорят везде и расскажут всем про Rust.
Ошибку они канпшна исправят, а вот эффект опстанется. Кароче пафос и перформанс.
Другео дело, что какое сообщество сейчас кого удивить просто рабочим кодом непонятно.
Много раз здесь повторяли. Это просто тесты. Это не тесты на совместимость. Их никто так не писал.Поэтому упоминание этих тестов в новостях, без оговаривания данного факта, является обманом.
> Много раз здесь повторяли. Это просто тесты. Это не тесты на совместимость.
> Их никто так не писал.
> Поэтому упоминание этих тестов в новостях, без оговаривания данного факта, является обманом.Ну, т.е. выводит du _какую-то_ сумму - а какую именно GNU Coreutils не интересно, лишь бы не пустоту. Выдает date -r file _какую-то_ дату (А может и не "дату" - "строку", во!) - и опять-таки, тесты не для совместимости сделаны - тесты хорошие!
Ляпотаааа... Вот прям даже не знаю, кто тут эээээ больший чудак выходит.
В GNU Coreutils люди код пишут. И предъявляют к нему требования. А тесты - дополнительная страховка.
Ну и вывод Busybox с Coreutils совпадает.. Так что, Д'Артаньян, перелогинься.
> В GNU Coreutils люди код пишут. И предъявляют к нему требования. А
> тесты - дополнительная страховка.
> Ну и вывод Busybox с Coreutils совпадает.. Так что, Д'Артаньян, перелогинься.Ну да, ну да: "государственная дума - не место для дискуссии"(Ц), а тесты - не для проверки корректности работы программы - а ну... Вот... Положено так. И вообще, не для вас писали! Вот, презерватив в кармане лежит - ЗАЩИЩАЕТ, а что карман тот "пиджака", который в шкафу... Но ведь есть же!
И нет, если вы не поняли, о чем я - "совпадение" или "не совпадение" реализации о качестве тестов говорит "ничего"
> И вообще, не для вас писали!Столько ёрничания, что бы попытаться замылить факт - что эти тесты люди писали для себя. А не для проверок на совместимость.
И в новостях трубить о прохождении тестов, как о проверки на совместимость - явно выраженная ложь.
>> И вообще, не для вас писали!
> Столько ёрничания, что бы попытаться замылить факт - что эти тесты люди
> писали для себя. А не для проверок на совместимость.
> И в новостях трубить о прохождении тестов, как о проверки на совместимость
> - явно выраженная ложь.А, т.е. если "для себя" то как бы и норм? Строка на входе выдала строку на выходе, программа работаит! А, цифирьки разные? Да пофиг, результат 0, пройдено!
> А, т.е. если "для себя" то как бы и норм? Строка на входе выдала строку на выходе, программа работаит! А, цифирьки разные? Да пофиг, результат 0, пройдено!Для себя - означает, что делают проверки которые им интересны и в работе которых на разных платформах они сомневаются.
Не было задачи обложить тестами 100% функциональности.
>Не было задачи обложить тестами 100% функциональности.И так везде, где речь идёт о just-for-fun. Пофиг, что работать может неправильно из-за отсутствия покрытия тестами, зато бесплатно!
да тут выяснилось страшное что нет стандарта никакого и правильного поведения для этих утилит и мы с этим живём уже давно просто на том факте что нам по большей части пофигу что этот ду должен показывать мы просто фиксим скрипты под акутальную версию этого ду пост фактум если вылезают проблемы. если бы не попытка авторов уутилс применить какуюто логику к тому что ду должен бы выводить в теории мы бы и не узнали что за гнутым ду никакой логики не стояло он просто что-то считал как считал а остальные жили под это подстраиваясь. очевидно что тесты для этого ду от которого мы не ожидаем никакого правильного поведения просто не могут покрывать никаких эдж кейсов выявляющих его неправильное поведение.
> нет стандарта никакого и правильного поведения для этих утилитhttps://pubs.opengroup.org/onlinepubs/9799919799.2024edition...
> если вылезают проблемы
Поведение соответствует заявленному.
> если бы не попытка авторов уутилс применить какуюто логику
..не соответствущую заявленной в стандарте. А также **ОШИБКА!!1** в подсчёте суммы.
> Почему язык, который должен был облегчить программирование только усложнил его?Ну что вы как маленький, решая 1 проблему - создали 100 новых. И получился такой себе брейнфак 2.0. Хотя современные C++ могут заспорить за это звание. Но это не точно.
>Проблема в том, что переписанные тесты переписаны также качественноГде воен против погр=аного раста увидел, что тесты переписаны?
Я правильно понимаю, что Столман и компания не правильно считали байты? И им показали как нужно.
Скорее, это совместимость с чем-то более ранним.
Факт в том, что uutils ломают совместимость между системами. Даже если это на самом деле баг, на это может быть что-то завязано.
> Даже если это на самом деле баг, на это может быть что-то завязано.Это не баг. Я нашёл.
Вот как описывается du в POSIX.1-2024: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/d...
> A file that occurs multiple times shall be counted and written for only one entry, even if the occurrences are under different file operands.
Иными словами это поведение -- часть стандарта.
> Иными словами это поведение -- часть стандарта.А какой-то линукс posix compliant?
Если нет, то какие вообще перетензии?))Нет никаких причин переносить наркоманскую логику разработчиков посикса, которые внезапно решили поменять поведение из реализации 2018 года на то. что цитируете вы.
2018 "It is implementation-defined whether a file that occurs under one file operand is counted for other file operands. The directory entry that is selected in the report is unspecified."
pubs.opengroup.org/onlinepubs/9699919799/utilities/du.html
А никаких претензий. Вы в своём праве считать новую логику "наркоманской" и не имплементировать её.
Если разработчики uutils решат положить болт на POSIX compliance, для СПО это может будет даже хорошо.
>Нет никаких причин переносить наркоманскую логику разработчиков посиксаЕсть. Поскольку без посикса это уже будет не замена gnu coreutils, а соврешенно другой проект.
И я считаю, что с этого и надо было начинать — объявить сабж заменой coreutils по духу, а не по букве. К счастью, программы не высекают в камне, а направление развития проекта можно поменять.
Они ничего не ломают, они изначально не заявляли 100% совместимость, но благодаря убуинам которые потащили их в прод не провери, все вопят о "сломанности".
Вообще то заявлено целью. Не сломано - да. Но, как обычно, не дописано.
> Они ничего не ломают, они изначально не заявляли 100% совместимость, но благодаря
> убуинам которые потащили их в прод не провери, все вопят о
> "сломанности".Вообще-то - 100% совместимость с GNU Coreutils там на github'е в project goals заявлена.
> Вообще-то - 100% совместимость с GNU Coreutils там на github'е в project
> goals заявлена.Обещать - не значит жениться.
>> Вообще-то - 100% совместимость с GNU Coreutils там на github'е в project
>> goals заявлена.
> Обещать - не значит жениться."Горизонт, Петька - он как КОММУНИЗМ - удаляется по мере вашего к нему приближения..."
Заявлена полная совместимость, а любая несовместимость считается ошибкой.
> Я правильно понимаю, что Столман и компания не правильно считали байты? И им показали как нужно.Ну вообще-то, если строго посмотреть на цифры, то в GNU Coreutils подсчёт как раз верен: если сначала считается подкаталог, а потом топ-каталог, то в топ-каталоге не учитываются файлы, уже подсчитанные в подкаталоге. А если сначала считается топ-каталог, то подкаталоги уже не считаются.
Честно говоря, я об этом не знал. Но если хорошенько подумать, это вполне логично. А вот то, что uutils выводит неверный total -- это неудобно совсем и 100% является ошибкой.
upd: выяснил, что это поведение -- часть стандарта POSIX. См #40
> Но если хорошенько подумать, это вполне логично.Где же логично?
Я попросил посчитать размеры нескольких каталогов - напр. некий общий каталог и каталоги каждого пользователя в нем.
Мне нужны реальные размеры каждого из них, а не сидеть и суммировать всех пользователей чтобы узнать правильный размер общего как это возвращает GNU
Ну вот ты и укажешь du -smc /home/* /home, и получишь именно то, что хочешь:
- по одной строке с суммой на каждый каталог пользователя
- строку с /home, где будет просуммировано всё, что не вошло в /home/*
- и строку total с корректным общим размером /home со всеми подкаталогамиАльтернативно, ты можешь указать du -md 1 /home, и тогда ты получишь:
- по одной строке с суммой на каждый каталог пользователя
- строку с /home, где будет учтено всё, что находится в /home со всеми подкаталогамиФишка нового поведения по стандарту 2024-го года как раз в том, что ты можешь получить размеры конкретных подкаталогов отдельно от того, что остаётся в топ-каталоге, плюс вывести корректный total.
Это более гибкое поведение: ты получаешь всё необходимое с одного запуска du, и не надо дополнительно второй раз его гонять с эксклудами. Удобно ж.PS: И это мы ещё не поднимали вопрос о том, что старое поведение выводило завышенный total, что делало данную строчку вообще невалидной.
но правильнее было бы либо всегда считать сначала подкаталог потом топ каталог либо наоборот.. даже если это требует пару проверок в парер засунуть..
> Я правильно понимаюНет. Раст не умеет считать: "total # больше фактического"
>> Я правильно понимаю
> Нет. Раст не умеет считать: "total # больше фактического"А /var # меньше фактического
этодругоепониматьнадо?
Раст, в uutils: 1540 + 35495 = 37035 != 37033!
Это как?! Даже сложение на расте неправильное.
> Раст, в uutils: 1540 + 35495 = 37035 != 37033!
> Это как?! Даже сложение на расте неправильное.Не, это ты не умеешь в доку.
--
> -m Display block counts in 1048576-byte (1 MiB) blocks.du -smc /var /var/log
939 /var
7 /var/log
945 total
--
О, не знал, что раст даже целочисленные количества складывать не умеет, но растманы заявляют, что "соответствует сумме", хотя не соответствует по факту. Вы уж определитесь сначала.
> О, не знал, что раст даже целочисленные количества складывать не умеет, но
> растманы заявляют, что "соответствует сумме", хотя не соответствует по факту. Вы
> уж определитесь сначала.И все бы хорошо, о Великий Воен Супротив Раста, но там выше - совсем не Раст. Там сишечка. Просто можно сначала округлить байтики до блоков и посчитать сумму, а можно наоборот. Угадай, что будет точнее.
Раст: 35495 /var
37034 totalТ.е. total по факту должен быть 35495 (реально занимаемое место), но раст выдал 37034 бессмысленных попугаев. Что такое "двойной взнос /var/log в сумму"? Растманы объяснить до сих пор не могут.
> Т.е. total по факту должен быть 35495 (реально занимаемое место), но раст
> выдал 37034 бессмысленных попугаев. Что такое "двойной взнос /var/log в сумму"?
> Растманы объяснить до сих пор не могут.Давай ты для начала найдешь там раст:
https://cgit.freebsd.org/src/tree/usr.bin/du?h=stable/13
>Давай ты для начала найдешь там раст:И? Что ты этим хочешь показать?
Очевидно, то, что даже среди программистов на Си существуют разные мнения о том, как считать размеры. Такие простые вещи надо разжёвывать?
> Очевидно, то, что даже среди программистов на Си существуют разные мнения о
> том, как считать размеры. Такие простые вещи надо разжёвывать?Пфф, если что механика работы софта проектируется, а не из носа программиста очередного выковыривается, предполагается ожидаемое поведение программы, а не как Васян напишет - так и поплывет... Короче, плохой пример...
> A file that occurs multiple times shall be counted and written for only one entryНо раст не знает, что такое стандарты.
Интернет тоже. Но работает, тем не менее. Чудо, да?
Спасибо всем, кто растолковал, кто не прав Столман или Растобои. А я подумал, что ну вот, наконец, получили все профит. Ан, нет. Ну и нарушать стандарты, это конечно не правильно. Эх, ну как здесь не сказать, читайте матчасть...
У утилиты du в AIX и Linux разные наборы аргументов. При этом AIX появился на свет раньше Linux. О каких стандартах вы говорите?
>для предотвращения переполнения стека
>В утилите mkdir устранено переполнение стекаЯ правильно понял, что если в случае сишки бичом являлся выход за пределы массива, то растеры рвут стек, потому что создают огромные объекты на нём и лепят рекурсию куда не попадя?
Рекламные буклеты про безопасность начали разваливаться, как только пошло реальное использование.
До спавна местных, недалеко ушедших от LLM евангелистов 3... 2...
ИИ это всего лишь инструмент, абыр
А в сишке диды, абыр
UB, абырвалг
Валг.
Ну не верю я, что уже года два как однотипные, буквально тасуемые на уровне фраз и предложений посты пишут реальные живые люди, а не мясные/программные боты с весами или методичкой.
Дык какие Воены (часто просто невменяемые, говорящие под кальку одни те же глупости, не читающие документацию, не разбирающиеся ни в чём вообще, зато имеющие собственное ничем не подкреплённое мнение), такой и уровень дискуссий с подобными Военами. Им, как горохом об стену.
ИИ не существует. Есть нейросети.
> переполнение стекаЭто шедевр раста! Умудриться завалить стёк на 64-битной платформе при создании каталогов...
БЕЗОПАСТНО завалить стек на 64хбитной платформе.
Главное, чтобы комар... чекер боровов нос не подточил.
Не думали о карьере артиста эстрады? Евгений Ваганович уже старенький.
> Не думали о карьере артиста эстрады? Евгений Ваганович уже старенький.Воена вдруг pripeklow
или так или ловите борова
- Этот алгоритм запрограммировать невозможно.
- Почему?
- Боровчекер запрещает.
Причём здесь Rust? Это одна из логических ошибок, от которых Rust не страхует.Далее. На некоторых системах каталогов и файлов в них может быть очень много. Поэтому не надо даже умудряться, чтобы переполнить стек.
Программировать на Rust нормально не получается, приходится клонировать все объекты.
> приходится клонировать все объекты.Дак вот почему они не смогли браузер переписать, и за что их выгнали из Мозилы.
Получается, конечно, и нет, не приходится. Но только людям, чьи когнитивные способности для этого достаточны. Остальным, да, не дано. Программирование вообще дано далеко не всем.
Из-за простоты Rust набежало много новичков, которые так делают.
Понятно, это неправильные программисты на расте.
ну, с учётом того, что на расте пишут исключительно и только веб-синьоры, - да
Они плохие прораммисты, потому что код без CVE получается? Ясно-понятно...
> потому что код без CVE получается?Не получается.
Ссылки будут, и как обычно сишник вызвал переполенение в комментариях?
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...
И это всё? За всё время существования Раста меньше, чем в Сишных поделиях за год. Мда...
Ты просил ссылки. Тебе их дали. Что не так?
https://app.opencve.io/cve/?vendor=rust-lang
> Из-за простоты RustБольше Hello World на нём написал?
Я при написании небольшого проекта на Rust после многолетнего опыта на C++ не заметил чего-то простого (относительно).
Очень странно. В Rust нет UB, наследования, кучи способов инициализации, возможности замены операторов и прочих сложностей Плюсов. Остаётся только догадываться, что у вас там за опыт такой многолетний. Rust, конечно, нельзя назвать простым, но при этом он гораздо проще монструозных Плюсов.
>Я правильно понял, что если в случае сишки бичом являлся выход за пределы массива, то растеры рвут стек, потому что создают огромные объекты на нём и лепят рекурсию куда не попадя?Нет, у вас, как у типичного местного "эксперта", проблемы с логическим мышлением.
Проблемы при работе с памятью - это типичная проблема для всех программистов, пишущих на Си сколь-либо сложное ПО. А, например, UB - вообще часть стандарта этого ЯП.
В то же время проблема переполнения стека не является типичной для всех программистов, использующих Rust. Отдельные личности могут допускать подобные ошибки, но это не относится ко всем программистам.
правильнее было бы переписать их на python
Правильнее вообще писать под задачу свой код. Собрал файлы которые тебе нужны сложил байты и посмотрел в своем приложении. А зачем там du и кому он нужен непонятно.
На рнр :^)
https://github.com/getgle/getgle-coreutils
‘-S’
‘--separate-dirs’Normally, in the output of du (when not using --summarize), the size listed next to a directory name, d, represents the sum of sizes of all entries beneath d as well as the size of d itself. With --separate-dirs, the size reported for a directory name, d, will exclude the size of any subdirectories.
вот очень похоже на (неявное) использование этого параметра
> total # больше фактическогоДа... Раст ещё и в арифметике не силён. Ожидаешь "disk usage" - а там ошибка.
> GNU Coreutils показывает в итоговой строке фактический размер, который указанные каталоги занимают на диске, но в раздельном списке показывает размеры каждого каталога с вычетом вложенных каталогов, из-за чего их размер получается меньше фактического. Кроме того, значения, выводимые в GNU Coreutils и Busybox, меняются в зависимости от порядка указания каталогов.Точно именно у раста в арифметике проблема? Текст новости не читаем?
> A file that occurs multiple times shall be counted and written for only one entry, even if the occurrences are under different file operands.у GNU есть стандарт, и делает всё строго по стандарту.
Раст: "мы даже числа правильно складывать не умеем". total # больше фактического, и НЕ соответствует сумме.
Тем временем GNU:> размер получается меньше фактического
Ну ясно-понятно...
> A file that occurs multiple times shall be counted and written for only one entry
> Разработчики ещё не решили трактовать ли данное расхождение как ошибку, так как с одной стороны в поведении uutils есть логика и тестовый набор GNU Coreutils не выявляет проблем, но с другой стороны несовместимости с GNU Coreutils предписано обрабатывать как ошибки и поведение Busybox соответствует GNU Coreutils.Ну понятное дело, что они "ещё думают". Они ведь радостно рапортуют о том, что "обеспечили совместимость на более, чем 80%". А тут происходит столкновение с реальностью, и выясняется, что удовлетворить оригинальному тестовому набору -- это не то же самое, что и обеспечить 100%-ю совместимость с исходным продуктом.
Ну в общем определенная логика даже есть. Как проводится сертификация на соответствие требованиям? Ну вот прогоняется тест сьют - все зеленое - на бамажка "соответствует". Ах, тест не все покрывает? Все равно, "соответствует" - вот внесете изменение в тесты, будет несоответствовать - исправим, а пока так.Логика конечно кривая и гниловатая - но определенно, есть.
Гниловатая или нет, но с учётом того, что как выяснилось, это поведение -- часть стандарта POSIX (см #40), судя по всему править баг им таки придётся.
> это поведение -- часть стандарта POSIX (см #40)Поправочка, стандарта POSIX 2024.
Т.е достаточно сказать "нам и 2018 хватит" и можно забить на
> править баг им таки придётся
>Логика конечно кривая и гниловатая - но определенно, есть.Думаю, пора вводить отдельное понятие "ржавая" логика))))
Вот есть формальная логика, а есть "ржавая" = профит)))
>Они ведь радостно рапортуют о том, что "обеспечили совместимость на более, чем 80%". А тут происходит столкновение с реальностьюГде вы столкновение-то углядели? Они ведь честно сообщают, что 100%-й совместимости пока нет, есть только на более, чем 80%. На это, кстати, и номер версии намекает.
Растаманы опять не смогли нормально переписать. На этот раз du - блин, просто возьмите и перепишите чтоб не было расхождения в поведении, для этого же язык и создавался.
Увы, но на раст принципиально невозможно перенести все UB/CVE сишного кода, если только unsafe обмазаться ради совместимости с кривым GNU поделием...
Им бы сперва работоспособность coreutils перенести...
Дык уже на 85% цель достигнута. И процес продолжается.
Ты что-то как-то очень толсто троллишь. Ты реально думаешь, что отличия в поведении du из-за того что в coreutils UB/CVE? Ну ведь вовсе нет, как бы ты ни пытался отмазать этих вебприматов - они просто не смогли переписать.
Они ведь и не заявляют, что уже всё сделано, да? Я к тому, что процесс продолжается.
> просто возьмите и перепишите чтоб не было расхождениядаже если в оригинале какой-то бред?
Типа копировать хpeновые подходы, главное совместимось?
Конечно же, главное -- совместимость. Вы же пишете прозрачную замену. Это в целях проекта заявлено -- но нет, ржавуны не перестают выбрыкивать.
О какой совместимости вы тут лепечете, если та же du (и не только она, а и много других подобных утилит, типа ps, sed, grep, find) в Linux и AIX имеет разный набор аргументов?
>Растаманы опять не смогли нормально переписать.На 85% цель достигнута. Но очередной воен опять не справился с фактами.
сколько лет они уже это переписывают и всё никак не перепишут?
есть же готовый код перед глазами, что сложного?
В 2020м начали. Сколько-то серьёзно вроде с 22го.
В код смотреть нельзя - нарушение gpl. А uutils на gpl переводить нельзя, иначе потом ЕЕЕшить будет дорого.
Разве переписанные программы на другой язык подпадают под действие лицензии GPL?
Производная работа - нельзя.
Нет, не попадают.
Производность работы нужно еще доказать.
Что весьма сложно, если в новом коде не будет ни строчки из старого.
Доказать нетрудно. Сравнение делает эксперт, а не робот, по смыслу, а не построчным стравнением.
Один раз доказал, и все эти ваши многолетние "переписывания" моментально становятся принудительно (решением суда) GPL-лицензированными.
Но ты продолжай уговаривать себя и других. Для пермиссивщиков норма - воевать не в ту сторону, и постоянно побеждать себя же самих.
> В код смотреть нельзя - нарушение gpl.Ой, не смешите мои тапочки. Смотрят поди еще как, только толку 0. Пойди и докажи, что смотрели, когда там код вообще другой.
Ахилл никогда не догонит черепаху
> Заявлен уровень совместимости 85.80% (было 83.91%).Немножечко беременна. Теперь у вас будет валиться 15 задач из сотни. Подумаешь мелочи какие. Чочо, почти 90 тестов не работают? Notabug, релизить надо - фонд отчеты KPI ждет, а то вообще грантов за безопасное переписывание не насыпят.
Ещё один, не умеющий в логику. Кто говорит, что работа уже закончена?
1540 /var/log
35495 /var
37033 total # больше фактического, но соответствует сумме /var и /var/logНе соответствует! 1540 + 35495 = 37035, а не 37033!
> 1540 /var/log
> 35495 /var
> 37033 total # больше фактического, но соответствует сумме /var и
> /var/log
> Не соответствует! 1540 + 35495 = 37035, а не 37033!Начнем с того, что в оригинале не 37033 а 37034, закончим тем, что "-m like --block-size=1M".
Все там соответствует. Особенно если не подменять последние циферки в "цитировании" 🙄.
du -smc /var/log /var
7 /var/log
942 /var
948 totaluu-du -smc /var/log /var
7 /var/log
942 /var
948 totaldu -sc /var/log /var
6708 /var/log
963712 /var
970420 totalcalc 6708 + 963712
970420
calc 970420/1024
947.67578125
Ай-ай, опять Воены облажались. Так вы никогда не остановите Ржавое Вторжение и не спасете Галактеку!
Начнём с того, что всё занимает 35495, а вот раст почему-то выдал 37033... И это ещё не касаясь округлений.
Подсказка для тех, кто не силён в математике:35495 /var
- это место, занимаемое всеми указанными файлами на диске.37033 total # больше фактического
- это то, что выдал растЧто такое 37033 - 35495 = 1538 ?
> Подсказка для тех, кто не силён в математике:
> 35495 /var
> - это место, занимаемое всеми указанными файлами на диске."Папа, где море?"
Подсказка №1 для Военов Супротив Раста:
du выше: https://cgit.freebsd.org/src/tree/usr.bin/du/du.c?h=stable/13Подсказка №2, вот отсюда:
https://www.opennet.ru/openforum/vsluhforumID3/138324.html#123
> Так, например, в стандарте POSIX.1-2018, написано[1]:
> A file that occurs multiple times under one file operand and that has a link count greater than 1 shall be counted and written for only one entry. It is implementation-defined whether a file that has a link count no greater than 1 is counted and written just once, or is counted and written for each occurrence. It is implementation-defined whether a file that occurs under one file operand is counted for other file operands.
>
Зря
Почему?
Насколько я помню, в целях проекта заявлено, что любое отличие от оригинала есть баг. Ржавуны, как же так, вы не можете даже переписать логику утилит 1:1?
Clean room implementation запрещает смотреть в гнутый код, в котором посиксной лажи напрогали вместо того, чтобы сделать нормально (зато на PDP-11 работает).
> В утилите tsort реализация алгоритма обхода DFS переведена с рекурсивного на итеративный метод работы для предотвращения переполнения стека.Молодцы, только такие вещи сразу нужно делать. К сожалению, в вузах всё ещё учат делать через стековую рекурсию вместо итеративной вместо того, что бы учить *не* делать.
В си почему-то не было переполнения стёка, а в расте - переполнение... Программисты на расте как-то по особенному пишут - намного кривее, чем на си?
Так GNU утилиты сколько лет существуют, естественно там уже много раз оптимизировано. Странно тоже самое требовать от нового проекта.P.S. хотя CVE до сих под закрывают в GNU utils, что какбы позорно.
ну во-первых, много лет не показатель, этот растаманский прожект тоже не вчера появился. во-вторых, что такое размер каталога, это сумма размеров файлов внутри, и/или плюс размер метаданных, или размер суммарно занимаемых блоков фс, а жесткие ссылки считаются по кол-ву, или как.> какбы позорно.
в отличии от всяких нтфсов, фс линукса активно развиваются, появляются новые, депрекейтят старые, конечно верхнеуровневые утилиты должны изменяться под подобные движения, система живет своей жизнью, за которой можно следить, а можно не следить, или даже не знать о существовании ее, что позорного то?
А с чего ты взял, что в сишной версии переполнения нет? В сишной версии переполнение есть при поиске цикличных зависимостей (detect_loop). В растовской версии это пофиксили.
ну и там пофиксят когда надо будет. это непричина генерировать кучу CO2
>это непричина генерировать кучу CO2Это формула угоекислого газа. А у амиака который выходит из анального отверстия не такая химическая формула.
Михаил тоже учился на химика. А стал широко известным в узких кругах линуксоидом. Почему? Очевидно потому, что в химии ему ничего не светило.
CH₄ же!
В uutils:
35495 /var
37034 total # больше фактическогоОчевидно же, что total должен быть 35495 (в GNU всё правильно показывается), а не 37034. К чему в расте сделали виртуальных попугаев, не соответствующих действительности?
за 25 лет никогда даже не пытался складывать эти циферки, типа а зачем, если при копировании на другую фс эти циферки станут другими, да и если удалять эти и записывать чтото на их место не факт что влезет, потому что разное кол-во файлов... du -h и там примерно можно прикинуть.> К чему в расте сделали виртуальных попугаев
В убунте как всегда придумали свой велосипед и пытаются всех на него пересадить, в этом плане они с растом фактически нашли друг друга, чинить то что никогда не ломалось, и радостно об этом рапортовать
Завёл три линукса - получил три разных результата. Все три верны. Математика пошла и повесилась в туалете.
А что местные ыксепрты молчат?
>так как с одной стороны в поведении uutils есть логика и тестовый набор GNU Coreutils не выявляет проблем, но с другой стороны несовместимости с GNU Coreutils предписано обрабатывать как ошибки и поведение Busybox соответствует GNU CoreutilsФактически это значит, что в любой момент логика gnu может поменяться, и тесты это не отловят.
> У утилитах stdbuf и uptime реализована поддержка платформы OpenBSD.
> Улучшена сборка и тестирование на платформе FreeBSD.А вот это уже интересно.
На бсд конечно есть свои утилиты, но почему бы не перейти на универсальные для всех плаформ и не пачкать руки об гну.
Гнушный tsort обрабатывает 100000 элементов за 56 секунд. Растовский за 2 секунды.Выбор очевиден.
> GNU tsort обрабатывает 100000 элементов за 56 секунд. Растовский за 2 секунды
$ wc -l ./tsort_input.txt
100000 ./tsort_input.txt
$ time tsort ./tsort_input.txt > /dev/null
real 0m0,107s
user 0m0,101s
sys 0m0,005sСкрипт генерации файла:
import randomdef generate_tsort_file(filename, num_nodes=100000, num_edges=100000):
"""
Генерирует файл для tsort с num_nodes узлами (1..num_nodes)
и num_edges рёбрами (зависимостями), где каждая зависимость — это пара (a, b), a < b.
"""
with open(filename, 'w') as f:
for _ in range(num_edges):
a = random.randint(1, num_nodes - 1)
b = random.randint(a + 1, num_nodes)
f.write(f"{a} {b}\n")if __name__ == "__main__":
random.seed(42) # для воспроизводимости (удалите или измените seed, если нужно)
generate_tsort_file("tsort_input.txt", num_nodes=100000, num_edges=100000)
print("Файл 'tsort_input.txt' успешно создан с 100000 случайными парами (a b, где a < b).")
Попробуй 100000 пар n -> n+1 где последняя n -> 1 (циклическая связь).На телефоне неудобно скрипт перепечатывать.
Первая строка в файле: 83811 85636
100000-я строка: 97424 83811
$ time tsort ./tsort_input.txt > /dev/null
real 0m0,105s
user 0m0,101s
sys 0m0,004s
```
/home/user: cat tsort_input.sh
#!/usr/bin/env bash
# Generate a long cyclic dependency chain (1 -> 2 -> ... -> N -> 1) to stress tsort's recursion
N=${1:-100000}
# Output edges forming a cycle: 1->2, 2->3, ..., (N-1)->N, then N->1
for i in $(seq 1 $((N-1))); do
printf "%d %d\n" "$i" "$((i+1))"
done
printf "%d %d\n" "$N" "1" # close the cycle (N -> 1)/home/user: bash tsort_input.sh | save -f tsort_input
/home/user: timeit { open tsort_input --raw | /bin/tsort }
/bin/tsort: -: input contains a loop:
[...]
56sec 18ms 880µs 110ns/home/user: /bin/tsort --version
tsort (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.Written by Mark Kettenis.
```
Специально ради тебя качнул бунту 25. И как-то чуда не произошло:
lubuntu@lubuntu:~$ time tsort ./tsort_input.txt > /dev/null
<...>
real 0m59.015s
user 0m57.733s
sys 0m1.084s
lubuntu@lubuntu:~$ tsort --version
tsort (uutils coreutils) 0.2.2
/home/user: tsort --version
tsort (uutils coreutils) 0.4.0/home/user: timeit { /home/user/.cargo/bin/tsort ./tsort_input_1mil out+err>| ignore }
4sec 502ms 483µs 869nsДидовский tsort за два часа не справился - пришлось прибить.
Убунту качать, что бы попробовать uu_tsort не нужно - достаточно сделать `cargo install uu_tsort` и собрать + поставить ровно вот эту утилиту.
Попробовал миллион пар - уже 2 часа жду, когда дидовский tsort завершит работу. Пока он только 100% cpu показывает.
... все это хорошо, наверно; только когда в какой-нибудь sort появится возможность сортировать по заданному пользователем шаблону?... или ждать XXII век?
давно есть. Читай man sort.
Ну в общем беш с сопутствующими утилитами - это не 22 век и никогда им не станет. Это безнадёжно устаревший подход к скриптам. Юзайте Nushell - там и язык нормальный с типами и структурами данных, и команды команды для скриптов богатые, и поддержка CLI флагов из коробки и параллельная обработка данных и много чего ещё.
Ой, да заманали вы своим снобизмом дешёвым. Юзайте вообще любой язык программирования, на котором можете программировать. В любом проекте я предпочту автоматизацию хоть на КОБОЛе ручному колдовству наполовину состоящему из поиска по ~/.bash_history чтобы посмотреть — как же мы это делали в прошлый раз? А для себя на локалхосте, так вообще без разницы на чём, просто бессмысленно обсуждать, у всего этого ровно один пользователь.
ИМХО, выглядит как классический пример UB(Undefined Behavior). Либо в спеку добавить и покрыть тестом, либо забить болт.
> Либо в спеку добавитьУ раста есть слабое место: отсутствие стандартов.
Даже если бы были, тащить в стандарты языка спеку на файловые утилиты - путь в никуда.
Место есть, но не факт, что слабое. Вон, у Интернета тоже нет стандарта. А он работает при этом.
давайте просто примем стандарт чтобы во всех графах у ду был фактический размер на диске. тогда это будет логичная и предсказуемая утилита показывающая полезные данные. посиксовский мем что если ты сначала посчитал подкаталог то посчитанный после каталог у тебя уменьшается потому что нельзя считать один блок дважды.. ну бред же. а если я в соседнем терминале эти блоки уже посчитал сегодня я вот сейчас что уже не второй раз их буду считать? почему ситуация когда я отдельными командами прошу подсчитать каталог и подкаталог отличается от ситуации когда я прошу их посчитать одной командой?
Ну ребят, первыми были ГНУ, и можно сколько угодно хаять их код и все остальное, но коль уж эти растеры собрались переписывать, пусть относятся с уважением и копируют поведение точь в точь.
Или они настолько неадекваты, раз думают что из за их поделия все мигом ломанутся переписывать тонны существующего софта? Типа, не хотим переписывать один в один, и заставим всех вокруг тоже переписыванием заняться, так что ли?
>заставим всех вокруг тоже переписыванием заняться, так что ли?так в этом и весь смысл Rust a и uutils - чтобы всех оторвать от использования GNU
Не поверишь, в предыдущем обсуждении, когда их поделка сломала обновления в ubuntu, они в таком духе и высказывались -- мол, нафига нам тащить весь этот дидов хлам в наши практически непогрешимые утилиты? как захотим, так и исделаем!
Проблему уже пофиксили. Но воен продолжает газифицировать лужи.
> Проблему уже пофиксилиКогда в uutils найдется новая порция багов, я вспомню этот пост.
Каким образом "новая порция багов" будет связана с этим постом? Я же выше говорил про то, что УЖЕ ИСПРАВЛЕНО, а не то, что МОЖЕТ БЫТЬ В БУДУЩЕМ ПОТРЕБУЕТ ИСПРАВЛЕНИЯ.Ну и в энный раз напомню, что язык Rust предотвращает не все возможные ошибки, а только определённый ограниченный их класс. Никак запомнить не можете?
Очевидно же, что у растоманов лицензия bsd и они при переписывании смотрят не в гнутый код(чтобы не нарушать лицензию), а в код freebsd, а там поведение как раз такое, как у них в итоге и получилось(потому что в freebsd посикс свежий ещё не догнали).
> копируют поведение точь в точьТы имеешь ввиду сохранять совместимость, чем они очевидно и заняты. А вот точь в точь не нужно - гнутые утилиты как минимум тормозные.
Это ты тормозной, научись пользоваться инструментами.
Если инструмент дефектный с момента появления на свет, то как ни учись, получится на выходе какаха. И ещё. Ты не можешь вручную крутить отвёртку быстрее электромоторчика. Поэтому профессионалы всегда выбирают для работы современные инструменты, они и безопасней и удобней намного в работе.
1. Инструмент не дефектный, RTFM;
2. Аналогии...ок. Все замены отверток, это не электромоторчик, а та же отвертка, но с разными ручками - мягкие, нарезные, деревянные и тп. А эти ещё решили, что отвертка не правильно работает, потому что должна работать как вилка.
Покажете многопочный grep? А ripgrep, например, как раз такой. Так что вполне себе корректная аналогия.
> 1. Инструмент не дефектный, RTFM;И CVE с ним связанные - это задумка такая?
>пусть относятся с уважением и копируют поведение точь в точьУ du в AIX и du в Linux есть непересекающиеся наборы аргументов. С какой утилиты копировать прикажете, эксперт? На всякий случай. AIX появился до Linux.
Правильной дорогой идёте товарищи.
Мне всё больше офтопик нравится, из-за этой вот всей свистопляски со "свободным" ПО. Один головняк сплошной от улучшателей и переписывателей.
******* придумывают сами себе проблем
Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания и удовольствие.
> Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания
> и удовольствие.Можно цитировать это в ответ на насмешки "опять у сишников дырень нашли"?
А ещё можно биться головой об стену. Это примерно то, чем от одного CVE к другому занимаются программисты, продолжающие использовать Си при написании современного сложного ПО.Rust, разумеется, далеко не идеал, уже есть языки и получше (хотя пока только на стадии альфа-версий). Но всё же он на порядок лучше Си. Однако "мышки (программисты) плакали, кололись, но продолжали есть кактусы (использовать морально устаревший хлам)".