LINUX.ORG.RU

GNU Coreutils 8.25

 ,


0

1

20 января была представлена новая версия GNU Coreutils — набора базовых утилит для работы с файлами, текстом и командной оболочкой (cp, mv, chown, ls, dd, echo, cat и т. д.). Новая версия включает 169 коммитов от 12 людей.

В новой версии:

  • В дополнение к команде base64 была добавлена команда base32;
  • Новые функции:
    • comm, cut, head, numfmt, paste и tail теперь имеют опцию "-z" ("--zero-terminated"), добавляющую в конец записи нулевой символ (NUL);
    • dd с опцией "--human-readable" преобразует информацию о размере в читаемый формат, например: «3441325000 bytes (3.4 GB, 3.2 GiB) copied»;
    • в утилиты md5sum, sha1sum, sha224sum, sha256sum, sha384sum и sha512sum добавлена опция "--ignore-missing", исключающая проверку несуществующих файлов;
    • printf теперь поддерживает спецификатор формата '%q', выводящий аргумент в формате, пригодном для большинства оболочек, показывающих непечатные символы в виде «$'...'»;
  • Исправления и улучшения:
    • mv больше не вызывает потери данных при удалении исходного каталога, указанного в параметрах несколько раз, если этот каталог является пунктом назначения;
    • утилиты, влияющие на директории (chmod, cp, rm и т. д.), теперь лучше работают с XFS;
    • stat -f --format=%T теперь выводит тип ФС для новых псевдо-ФС «bpf_fs», «btrfs_test», «nsfs», «overlayfs» и «tracefs», а также для «acfs»;
    • все утилиты выводят аргументы, полученные от пользователя, в сообщениях об ошибках;
  • Изменения:
    • join, sort и uniq с опцией "--zero-terminated" воспринимают '\n' как разделитель полей;
    • ls теперь экранирует имена файлов, что подходит для использования их в командной оболочке и при выводе в терминал.

>>> Подробности

★★★★★

Проверено: leave ()

Ответ на: комментарий от Cheater

Скрипты, которые парсят вывод ls, должны быть сломаны (а их авторы — умерщвлены посредством медленного потрошения).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Cheater

Как же всё-таки полезно читать оригиналы вместо низкокачественных переводов на ЛОРе:

«ls now quotes file names unambiguously and appropriate for use in a shell, when outputting to a terminal».

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

anonymous ()
Ответ на: комментарий от intelfx

Эти скрипты не сломаются. stdout != tty.

anonymous ()
Ответ на: комментарий от intelfx

Когда хейтят Unixway логичнее всего думать, что хейтят виндузятники.

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

полезно читать оригиналы

Исходники читать ещё полезнее. И, если присмотреться к тому патчу, что я привёл выше, то, действительно, становится очевидно, что stdout и tty обрабатываются по-разному. Однако, многим нужен также и порядок в tty. Так что, опции и патчи всё равно полезны.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Я говорю про перенаправление вывода одной программы на ввод другой. Вот это Unixway. И тут уже не важно какие это программы. Даже если первой является ls. А вывод ls может обрабатываться по-разному. Например, так:

$vxtst = `ls *\.v???\.* 2>/dev/null | wc -l`;
или так:
$strtv = `ls | sed 's/^.*\\.v//;s/\\..*\$//' | head -n 1`;
или так:
djvm -c $2 `ls $1/*.djvu`

saahriktu ★★★★★ ()

В дополнение к команде base64 была добавлена команда base32

Ну прямо невероятно нужная и полезная фича. И как мы без этого жили?

anonymous ()
Ответ на: комментарий от saahriktu

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

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf "%s\n" *?

intelfx ★★★★★ ()
Ответ на: комментарий от madjestic

Потому что ls — это утилита с человекочитаемым выводом, который никто не обещал не изменять.

Потому что делать ls <pattern> примерно настолько же избыточно, как и засовывать котов в трубу, т. к. тебе нужно не вывести информацию о файлах, а тупо напечатать аргументы, разделяя их переводами строк. Для этого есть printf(1).

intelfx ★★★★★ ()
Ответ на: комментарий от false

Как у тебя бомбит-то. Лёд приложи, полегчает. Или к врачу сходи.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf «%s\n» *?

Шелл есть не всегда. Иногда есть причины в программе на C использовать команды такого рода вместо системных вызовов.

И оправдание «никто не обещал» не применимо к данному случаю: и без всяких обещаний было понятно, что без особых причин вывод ls менять никто не будет — в конце концов даже для людей, не для скриптов, тех кто просто пользовался командой ls день ото дня, не особо приятно любое беспричинное измение её поведения, ибо оно логично требует признания, что до этого вывод ls был неидеален, с чем уважающий себя пользователь Линукса не согласится.

anonymous ()
Ответ на: комментарий от intelfx

Зачем в этих примерах тяжеловесный ls

Не так уж он и тяжеловесный. Потеря каких-нибудь 0.003s слабо отражается на производительности. И если уж экономить на таких спичках, то только после выпиливания более тяжеловесных монстров: графических браузеров с JavaScript'ом, офисных пакетов, Java,... и т.д. На них явно теряется на порядки больше системных ресурсов и времени.

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

Зачем в этих примерах тяжеловесный ls, когда обработка звёздочек делается на уровне шелла, и там достаточно тупого printf «%s\n» *?

Шелл есть не всегда. Иногда есть причины в программе на C использовать команды такого рода вместо системных вызовов.

Ты сам-то понял, что сказал? :]

  • я говорю про printf(1), а не про printf(3)
  • даже printf(3) всё равно не системный вызов
  • речь вообще не про Си
  • покажи мне систему, в которой нет шелла и нет /bin/printf, но есть /bin/ls
  • я изначально говорил про шелл-скрипты, с какой радости ты начал рассматривать системы, в которых нет шелла?
intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Откуда у вас всех привычка приводить совершенно нерелевантные сравнения тёплого с мягким и выдавать их за аргументы?

Потеря каких-нибудь 0.003s слабо отражается на производительности.

Ага, а если в цикле?

И если уж экономить на таких спичках, то только после выпиливания более тяжеловесных монстров <...> На них явно теряется на порядки больше системных ресурсов и времени.

Логическая ошибка класса «а у вас негров линчуют». Торможение шелл-скрипта, в котором в цикле вызывается ls вместо printf, никак не связано с торможением «тяжеловесных монстров», которых вообще в системе может не быть.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Ты говорил про парсинг вывода ls и что его можно заменить на printf «%s\n» *. Это неверно, потому что парсить вывод ls надо нетолько в скриптах, но и, например, в программе на C. Но в программе на C нет printf «%s\n» *. Ну то есть конечно можешь вызвать «sh -c printf «%s\n» *» вместо «ls», но это ещё больший костыль, чем парсинг ls.

anonymous ()
Ответ на: комментарий от intelfx

Ага, а если в цикле?

А если нет? ls в цикле - частный случай. А Вы рубите с плеча глобально. Мол, прописал ls в скрипт или софтину - пройди на потрошение за костыль. Даже если цикл никто и не собирался прикручивать.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от anonymous

Представь себе — чтобы вызвать из программы на Си /bin/ls с паттерном, всё равно нужно воспользоваться шеллом, потому что сам по себе ls не умеет раскрывать звёздочки :]

Это уже не говоря о том, что _в программе на Си_ нужно использовать glob(3) и readdir(3), а за костылирование с консольными утилитами — отрывать руки.

intelfx ★★★★★ ()
Ответ на: комментарий от goingUp

до появления книгопечатания(Гутенберг это вот всё) - каждым переписчиком

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

большинство же проекций Библии в реальный мир обязаны быть дефектными.

ну а уж если копать в сторону источника Q https://en.wikipedia.org/wiki/Q_source . . .

ps. вообще познавательно для ознакомления книги пророков (где каждая 3-4 странички)

qulinxao ★★☆ ()

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

А есть уже патч к coreutils, который отключает эту поттерингщину?

Lavos ★★★★★ ()
Ответ на: комментарий от Lavos

поттерингщину

Это POSIX, раньше только не по умолчанию было.

anonymous ()
Ответ на: комментарий от intelfx

Если уж Вы такой специалист по выпиливанию костылей, то может тогда подскажете как убрать костыли отсюда?

FLZLST=`tar tvf $1 | awk '{ print $6 }'`
# pointer to filenames array
CUR_PTR=0
MAX_PTR=`echo "$FLZLST" | wc -l`
# filling array
for fileindx in `seq 1 $MAX_PTR` ; do
        filename[$((fileindx - 1))]=`echo "$FLZLST" | head -n $fileindx | tail -n 1`
done

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Работает, только пришлось подправить чуток пару строк:

$ head -n2 /etc/portage/patches/sys-apps/coreutils/coreutils_8.25_ls_literal.patch 
--- src/ls_orig.c   2016-01-14 15:16:23.000000000 +0300
+++ src/ls.c        2016-01-22 01:08:01.174295814 +0300
Спасибо!

Lavos ★★★★★ ()
Ответ на: комментарий от qulinxao

до появления книгопечатания(Гутенберг это вот всё) - каждым переписчиком

Я читал, что ошибки вычитывали и неправильные копии уничтожали. В любом случае вбрасывать, что Библия прям _переписывалась_ несколько раз слишком толсто.

источника Q

Был источник Q, или не было источника Q, это не аргумент, что Библия переписывалась.

goingUp ★★★★★ ()

dd с опцией "--human-readable" преобразует информацию о размере в читаемый формат

Ура!

mix_mix ★★★★★ ()
Ответ на: комментарий от Cheater

Половина самописных скриптов, где своя реализация экранирования, сломается тут же на месте.

Зачем тебе ls в скриптах?

dexpl ★★★★★ ()
Ответ на: комментарий от saahriktu

Какая макака под кислотой это писала?

readarray -t filename < <(tar -tf "$1")

Не? Вариант с именованными каналами вместо process substitution (для грёбаных микроволновок) тоже возможен.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от goingUp

считаю полезным ознакомление с:

1. https://vk.com/doc-32395542_380013642

2.https://psoberoi.github.io/stepanov-civilization/canon.html

ps. ну и Септугианта и Библия Джона ну и наш(РИ) 1868? перевод несколько не идентичные тексты - ибо при переводе всегда дрейфует семантика - и даже сам язык в отличии от текста плывёт со временем.

qulinxao ★★☆ ()
Ответ на: комментарий от goingUp

ps. вообще познавательно для ознакомления книги пророков (где каждая 3-4 странички)

qulinxao ★★☆ ()

Здравствуйте!

Воспитать человека интеллектуально, не воспитав его нравственно, - значит вырастить угрозу для общества. Рузвельт.

anonymous ()
Ответ на: комментарий от intelfx

Представь себе — чтобы вызвать из программы на Си /bin/ls с паттерном

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

Это уже не говоря о том, что _в программе на Си_ нужно использовать glob(3) и readdir(3)

Обычно да, но ситуации бывают разные

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

Ты слишком зациклен на своей ненависти к «костылированию». Тру-юниксоид должен относиться к костылям с больших уважением. Вся UNIX и всё что из неё растёт есть собрание костылей бай-дизайн.

anonymous ()
Ответ на: комментарий от anonymous

Нет, я всё равно не понимаю, зачем в программе на Си нужно вызывать ls (с любыми аргументами) и парсить его вывод.

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Хоть я и не согласен с утверждением в рамках тривиальных однострочников типа:

 ls | grep -i "foobar" 
, это заставило меня прочитать 'info corutils'. Узнал многонового.

Спасибо.

madjestic ()
Ответ на: комментарий от intelfx

в Юникс среда программирования Пайка+Кернигана отличная глава про пикл и банч.

qulinxao ★★☆ ()
Ответ на: комментарий от goingUp

Молодой монах принял постриг, и в монастыре первым его заданием было помогать остальным монахам переписывать от руки церковные уложения, псалмы и законы.
Поработав так неделю, монах обратил внимание, что все переписывают эти материалы с предыдущей копии, а не с оригинала. Удивившись этому, он обратился к отцу-настоятелю:
— Падре, ведь, если кто-то допустил ошибку в первой копии, она же будет повторяться вечно, и её никак не исправить, ибо не с чем сравнить!
— Сын мой, — ответил отец-настоятель, — вообще-то мы так делали столетиями. Но, в принципе, в твоих рассуждениях что-то есть!
И с этими словами он спустился в подземелья, где в огромных сундуках хранились первоисточники, столетиями же не открывавшиеся. И пропал.
Когда прошли почти сутки со времени его исчезновения, обеспокоенный монах спустился в те же подвалы на поиски святого отца. Он нашёл его сразу. Тот сидел перед громадным раскрытым томом из телячьей кожи, бился головой об острые камни подземелья и что-то нечленораздельно мычал. По покрытому грязью и ссадинами лицу его текла кровь, волосы спутались, и взгляд был безумным.
— Что с вами, святой отец? — вскричал потрясённый юноша. — Что случилось?
— Celebrate, — простонал отец-настоятель, — слово было: «celebrate» а не «celibate»!

ps: celebrate — праздновать, радоваться;
celibate — воздерживаться .

anc ★★★★★ ()
Ответ на: комментарий от goingUp

The Hebrew Bible and the Greek New Testament were revised into their present forms by redactionists who may have shared very little with the original authors whom they were editing. Cervantes, with unsurpassed mirth, parodied unto death his chivalric forerunners, while we do not have the texts of Homer's precursors

qulinxao ★★☆ ()

Нормально. Скоро получим. :)

x86_64 Testing coreutils 8.25-1

pethead ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.