LINUX.ORG.RU

GNU Coreutils 8.13

 ,


0

1

Джим Мейеринг (Jim Meyering) объявил о выходе GNU Coreutils 8.13.

Новая версия включает более 200 коммитов от 18 разработчиков, а также более 1000 коммитов из gnulib, внесённых со времени выхода Coreutils 8.12.

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

Исправление ошибок:

  • chown и chgrp теперь корректно работают с опциями -v и --from, то есть для файлов, которые не удовлетворяют указанным в --from UID:GID, выводится их текущий владелец, а не новый владелец остальных файлов (ошибка появилась в sh-utils-2.0g);
  • cp -r ранее могла ошибочно изменить права доступа у существующих каталогов (ошибка из coreutils версии 6.8);
  • cp -u -p до этого времени не удавалось предотвратить дублирование жёстких ссылок для каждой актуальной копии файла в пути назначения, то есть, если s/a и s/b являются жёсткими ссылками и файл dst/s/a актуален, cp -up s dst скопирует s/b в dst/s/b вместо того, чтобы просто создать ссылку с dst/s/b на dst/s/a (видимо, эта ошибка существует с самого начала);
  • использование памяти утилитами rm, du, chmod, chgrp, chown, chcon больше не пропорционально числу файлов в каталоге, соответственно, если ранее работа с каталогом, содержащим 4 миллиона файлов, могла потребовать примерно 1 гигабайт оперативной памяти, то теперь требуется лишь около 30 мегабайт;
  • pr -T более не игнорирует параметр LAST_PAGE — позицию, где нужно остановиться (ошибка появилась в textutils-1.19q);
  • split --number l/... более не создаёт посторонних файлов (ошибка из coreutils-8.8);
  • timeout теперь отправляет сигналы командам, создающим свои группы процессов, и нормально работает при запуске вместе с дочерним процессом (ошибка добавлена в версии 7.0 coreutils);
  • unexpand -a теперь выравнивает правильно, если за пробелами следовал символ табуляции, поскольку в этом случае пробелы отбрасывались, приводя к нарушению выравнивания — введена проверка, не следует ли символ табуляции за пробелами (ошибка появилась в coreutils-5.3.0).

Изменения в поведении:

  • cp -au при явном указании --preserve=links теперь может замещать более новые файлы в каталоге назначения, чтобы отображать жёсткие ссылки из источника;
  • chmod, chown и chgrp теперь отображают оригинальные атрибуты, когда указываются опции -v и -c.

Новая функциональность:

  • date теперь обрабатывает строки в формате ISO 8601 с «T» в качестве символа-разделителя, такие как «2004-02-29T16:21:42» или «2004-02-29T16:21:42.333-07:00» (с указанием часового пояса и долей секунды);
  • md5sum, sha1sum, sha224sum, sha384sum и sha512sum с опциями --strict --check теперь возвращают ненулевой результат (выдают ошибку) при любой некорректной строке на входе, а не ограничиваются просто предупреждением;
  • split --filter=CMD позволяет пропустить вывод команды через фильтр CMD; CMD в свою очередь может использовать значение переменной окружения $FILE, которая содержит имя выходного файла во время каждого запуска CMD, например, если мы хотим разбить файл на три приблизительно равные части и сжать их, то теперь это может быть сделано командой split -n3 --filter='xz > $FILE.xz' big (обратите внимание, что кавычки должны быть одинарными, а не двойными);
  • timeout принимает новую опцию --foreground для поддержки команд, запускаемых не напрямую из командной строки, если команда интерактивна или должна получать сигналы из терминала.

Улучшения:

  • cp -p теперь копирует тривиальные NFSv4 ACLs на Solaris 10 (ранее эта команда ошибочно применила бы нетривиальные ACL к файлу назначения);
  • благодаря улучшениям в gnulib, cp и ls теперь поддерживают ACL в системе HP-UX 11.11;
  • df теперь поддерживает дисковые разделы величиной более 4TiB в MacOS X 10.5 и новее и AIX 5.2 и новее;
  • join --check-order теперь выводит сообщение «join: FILE:LINE_NUMBER: bad_line» для неотсортированного файла, а не просто «join: file 1 is not in sorted order»;
  • shuf гораздо более эффективно выводит небольшие подмножества больших перестановок, например, `shuf -i1-$((2**32-1)) -n2' больше не потребляет память в непомерных количествах;
  • stat -f теперь распознаёт файловые системы GPFS, MQUEUE и PSTOREFS;
  • timeout теперь поддерживает доли секунды для задания интервалов.

Отказ от изменений:

  • в cp не будет добавлен индикатор прогресса, эта функциональность признана излишней, а тем, кому такой индикатор необходим, рекомендовано использовать программу rsync.

Исходный код

>>> Сообщение на Саванне

★★★★★

Проверено: svu ()
Последнее исправление: Zhbert (всего исправлений: 6)

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

If rsync is not installed, perhaps you can install it. At worst, you can build it yourself.

If you really need to know what a cp process is doing, you can also run strace on it.

Джим Мейринг — кэп и тролль, да :)

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

ЛОЛШТО?

$ (cd /usr &&  tar cf - . ) | pv | (cd ~/tmp/1 && tar xf - )
18,5MB 0:00:08 [ 1,1MB/s] [                    <=>                                ]
geekless ★★
()
Ответ на: комментарий от YYY

Кстати, и использование в твоем алгоритме «cd blbla ;» вместо «cd blbla &&» — это фейл.

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

ВНЕЗАПНО, большой файл «ненужный монстр» rsync скопировал быстрее, чем куда более простой cp. А при копировании кучи маленьких файлов 6-кратное отставание rsync-а вызвано, конечно же, отображением прогресса копирования.

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

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

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

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

> Читается, как будто её специально туда запилили.

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

anonymous
()

Поздравляю все прогрессивное человечество с этой замечательной новостью.

в cp не будет добавлен индикатор прогресса...

lol, они что всерьез эту фичу рассматривали? Не нужно ни с какой стороны вообще. Да и прогресс чего выводить? Файлов? Байтов? А если содержимое каталога изменилось со времени сбора статистики?

A-234 ★★★★★
()
Ответ на: комментарий от nt_crasher

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

Да, но некоторые умные разработчики все-таки думают головой ПЕРЕД тем, как добавлять все подряд фичи в программу. :)

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

И это не считая кучи тонкостей, вроде того, по чём делать прогрессбар (по размеру файлов или количеству, с учетом каталогов или без), и того, что делать с non-regular файлами (ну-ка, нарисуй мне прогрессбар операции `cp /dev/cdrom image.iso`)

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

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

>> использование памяти утилитами rm, du, chmod, chgrp, chown, chcon больше не пропорционально числу файлов в каталоге, соответственно, если ранее работа с каталогом, содержащим 4 миллиона файлов, могла потребовать примерно 1 гигабайт оперативной памяти, то теперь требуется лишь около 30 мегабайт;

Хм. Никогда не замечал. Числа немного не сходятся, у меня на 4 миллионах получилось около 700МБ, но пропорциональность действительно есть:

$ for count in 1000 10000 100000 1000000; do mkdir testdir; for i in `seq $count`; do echo $i > testdir/$i; done; /usr/bin/time -f "$count files\t%Mk mem" rm -rf testdir; done
1000 files      704k mem
10000 files     2080k mem
100000 files    18236k mem
1000000 files   178280k mem
Кстати, на мелком ноуте с reiserfs этот тест занял около 10 минут, но прошел абсолютно незаметно для остальной системы, мыша не тормозила, окошки переключались. А что скажет на этом тесте ваша любимая файловая система? Btrfs есть у кого, проверить?

>> в cp не будет добавлен индикатор прогресса, эта функциональность признана излишней

> Не торт. Жлобы.

Unix-way же! Каждая утилита занимается своим делом. Для прогрессбаров другие утилиты есть. :)

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

> Unix-way же! Каждая утилита занимается своим делом. Для прогрессбаров другие утилиты есть. :)

Этих юниксвейных утилит с прогрессбаром - их нет. Чтобы сделать эти «другие утилиты», cp должен уметь считать статистику. А пока он это не умеет, нет никакого unix-way-я, т.к. все «утилиты с прогрессбаром» — это комбайны, реализующие как прогрессбар, так и собственный велосипедный аналог cp.

Сколько раз объяснять очевидное?

geekless ★★
()
Ответ на: комментарий от A-234

> А если содержимое каталога изменилось со времени сбора статистики?

А если ты завтра выпадешь из окна и помрёшь?

Тебе не кажется, что в подобных частных случаях никто и не ожидает корректности статистики? Не говоря уж о том, что копировать каталог, в котором идёт запись — это признак эталонного ССЗБ.

geekless ★★
()
Ответ на: комментарий от A-234

> Да и прогресс чего выводить? Файлов? Байтов?

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

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

Ваш кругозор удручает, никогда не слышали о консольных торрент-клиентах и файловых менеджерах? Я понимаю, мир обошелся с вами жестоко, вот и разработчики GNU coreutils не разделяют ваших взглядов на удобство консольных утилит. Нужны прогресс бары так чего mc не воспользоваться?

A-234 ★★★★★
()
Ответ на: комментарий от geekless

Зачем cp для статистики

Когда мне нужно прикинуть, сколько осталось, то я делаю что-то вроде

du -s "$1" # смотрю сколько было
cp -a "$1" "$2" &
watch du -sh $2 # смотрю сколько скачалось

Кто мешает это автоматизировать? И зачем для этого калечить cp? Хотя SIGUSR1 с указанием количества, скопированного этим процессом, было бы неплохо. Кстати, а в статистике по процессам такого нет? В Windows диспетчер задач позволяет увидеть «прочитано байт» и «записано байт» для каюдого процесса. Может такое можно штатно в Linux сделать?

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

> Этих юниксвейных утилит с прогрессбаром - их нет. Чтобы сделать эти «другие утилиты», cp должен уметь считать статистику. А пока он это не умеет, нет никакого unix-way-я, т.к. все «утилиты с прогрессбаром» — это комбайны, реализующие как прогрессбар, так и собственный велосипедный аналог cp.

Ты не понял ничего. «Unix-way: do one thing and do it well». Переводя на русский - для каждой задачи есть свои инструменты. cp - это инструмент для копирования. Он только копирует, без прогрессбаров, зато копирует любые файлы и быстро. А теперь запускаем mc, у него другая задача - сделать красивый консольный интерфейс с прогрессбаром, для этой задачи он умеет копировать с прогрессбаром, зато не все, скопируй-ка /dev/cdrom в mc. И т.д.

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

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

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

> Я понимаю, мир обошелся с вами жестоко

Скорее с вами.

никогда не слышали о консольных торрент-клиентах и менеджерах?

вот и разработчики GNU coreutils не разделяют ваших взглядов на удобство консольных утилит.

Ты или крестик сними, или штаны надень.

Нужны прогресс бары так чего mc не воспользоваться?

Еще один любитель комбайнов? Стремление к изобретению велосипедов и леплению комбайнов «100500 функций в одном» — серьёзная эпидемия, охватившая ПО под юникс в XXI веке из-за нашествия программистов, вскормленных виндой.

Тебе хоть раз приходило в голову, что подсчитать статистику по файлам ДО начала копирования, копировать файлы + считать статистику скопированного, а также выводить пользователю информацию о ходе копирования — это три РАЗНЫХ задачи, которые следует реализовывать РАЗНЫМИ утилитами? И что потом каждую из этих утилит можно применять отдельно, для других целей. Не изобретая очередной mc.

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

geekless ★★
()
Ответ на: Зачем cp для статистики от monk

> Когда мне нужно прикинуть, сколько осталось, то я делаю что-то вроде

watch du -sh $2


Эпичный костыль. От того, что он тебе родной и привычный, он не перестаёт быть костылём.

И зачем для этого калечить cp?


Кто тут предлагал калечить cp? Или ведение статистики — это калечение программы? Ну-ка живо и решительно выпилил мне ведение логов из апача, а то ишь, совсем искалечили бедный веб-сервер.

geekless ★★
()
Ответ на: Зачем cp для статистики от monk

Кстати, а в статистике по процессам такого нет? В Windows диспетчер задач позволяет увидеть «прочитано байт» и «записано байт» для каюдого процесса. Может такое можно штатно в Linux сделать?

Куда уж нам убогим без винды. Да все есть

cat /proc/PID/io

Вы вообще поинтересуйтесь тем что такое proc-fs, много неожиданного обнаружите.

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

Ты упорот и совершенно ничего не знаешь о юниксвее. Иди кури матчасть до просветдения.

geekless ★★
()
Ответ на: Зачем cp для статистики от monk

> В Windows диспетчер задач позволяет увидеть «прочитано байт» и «записано байт» для каюдого процесса. Может такое можно штатно в Linux сделать?

atop, iotop, iostat, /proc/PID/io... на выбор. :)

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

К чему столько эмоций, как будто я вашу любимую канарейку задушил.

Стремление к изобретению велосипедов и леплению комбайнов «100500 функций в одном» — серьёзная эпидемия, охватившая ПО под юникс в XXI веке из-за нашествия программистов, вскормленных виндой.

Вот эту гениальную фразу перед зеркалом каждый день. Или вы всерьез думаете что программисты GNU тоже виндой вскормлены? Тогда вам к доктору.

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

A-234 ★★★★★
()
Ответ на: комментарий от geekless

> подсчитать статистику по файлам ДО начала копирования, копировать файлы + считать статистику скопированного, а также выводить пользователю информацию о ходе копирования — это три РАЗНЫХ задачи, которые следует реализовывать РАЗНЫМИ утилитами?

Верно. Из этих трех задач cp занимается только второй. Какой из этого вывод? Надо добавить в cp прогрессбар? Неверно. Надо добавить туда вывод статистику по текущему состоянию (сколько файлов и каталогов обработано, какой суммарный размер). И выводить ее, например, при получении SIGUSR1. Это вполне юниксвейно, не влияет на производительность, и патч будет не слишком сложным. Так напиши его, в чем вопрос-то? Такой патч никто не предлагал же.

А просить прогрессбар в cp - это глупо.

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

> Тупорылое упорство разрабов coreutils не даёт возможности делать нормальные фронтэнды для cp, из-за этого любому ПО, которое хочет копировать файлы с отображением статистики, приходится велосипедить собственное cp.

В таких случаях иногда забавно послушать Торвальдса :) Он любит что-нибудь этакое высказать про считающих себя самыми умными разработчиков :)

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

В /proc есть информация по открытым файлам и количеству переданных байт. Какой еще статистики не хватает?

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

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

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

Вообще действительно странно. Могли сделать его необязательным, вроде как в rpm -ivh

hobbit ★★★★★
()

> тривиальные NSFv4 ACLs

NFSv4 или я чего-то не знаю? Если все-таки NFS - забавно, опечатку Джима оттранслировали и тут, и на linux.ru, и на опеннете.

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

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

Тоже вариант, кстати.

hobbit ★★★★★
()

статистика не нужна, хорошо, что не стали делать.

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

http://lists.gnu.org/archive/html/coreutils/2011-07/msg00068.html

I would like to implement a progress bar in cp, would that patch be accepted? Is there any reason not to do it? - Diogo Sousa

Well the thinking at the moment is it's a marginal feature. Given that one can already use rsync for this we don't think it needs to be added to cp. - Pádraig Brady

If cp had every feature of rsync then it would be rsync.

typical.

людям не нужен какой-то там 'кусок функционала rsync'. людям нужно копировать файлы. и по возможности с удобствами. Ваш КО - специально для Крутых Разработчиков.

- давайте сделаем в нашей машине складывающиеся сидения, чтобы багажник был побольше?

- nah, it's a marginal feature. Use ЗИЛ for this.

$ ls -ldogh /bin/cp /usr/bin/rsync | awk '{print $3, $7}'
116K /bin/cp
393K /usr/bin/rsync

And if you would like to have one of the features available in rsync then it is better to be using rsync instead. - Bob Proulx

ZOMFG!!111 оно в целых три раза жырнее!!1111 (расскажите кто-нибудь ему, что 116K в embedded ОСях это такой же оверкилл для одного лишь cp как и 393 - там всё равно busybox используется).

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

> расскажите кто-нибудь ему, что 116K в embedded ОСях это такой же оверкилл для одного лишь cp как и 393 - там всё равно busybox используется

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

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

И это будет -SIGUSR1 как в dd FTGJ!!

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

Xenesz ★★★★
()
Ответ на: комментарий от A-234

>в cp не будет добавлен индикатор прогресса...

lol, они что всерьез эту фичу рассматривали?

Новое слово в релизах: won't-change.log :)

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

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

Наконец-то до тебя доперло.

geekless ★★
()
Ответ на: комментарий от A-234

> если можно сесть и патчик написать?

В списке FR и багфиксов, которые я пилю для опенсорс софта, патч для cp стоит где-то в хвосте. Не говорите мне, что мне делать, и я не скажу вам...

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

Судишь всех по себе?

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

...патч для cp стоит где-то в хвосте

Как, вам в cp еще чего-то не хватает?

Судишь всех по себе?

Да я вроде тут еще никогда в истериках не бился, такую малость как SIGUSR1 к cp я бы прикрутил сам, без лишнего трепа. Нет, если вы в отчаянии то только попросите и я сделаю вам патч не позднее следующего понедельника.

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

> Да я вроде тут еще никогда в истериках не бился, такую малость как SIGUSR1 к cp я бы прикрутил сам, без лишнего трепа. Нет, если вы в отчаянии то только попросите и я сделаю вам патч не позднее следующего понедельника.

Отлично. Делайте. Ваши понты и трололо меня не интересуют, меня интересует результат.

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

А вот это уже разговор, коллега :) Договорились.

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

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

Судя по комментариям в этой теме ЛОР будет просто счастлив, если этот патч будет сделан. :)

А по теме, выводить надо как минимум 4 числа:
* объем записанных байт, очевидно
* количество обработанных файлов, не созданных/записанных, а обработанных из каталога источника, на случай cp -u, например. Плюс не забываем о том, что cp умеет не только копировать, но еще и ссылки создавать, в этом случае объем записанных байт будет равен нулю, а счетчик пройденных файлов будет расти
* количество пройденных каталогов, опять-таки не созданных, а именно пройденных, потому что при рекурсивном копировании часть каталогов могла уже существовать
* количество секунд от начала копирования

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

Получится что-то вроде:

processed: 24 directories, 1584 files, 18953496 bytes written, 75 seconds

Эту строку надо выводить в ответ на SIGUSR1.

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

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

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

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

За подсказку по поводу формата строки - спасибо, в таком виде и буду выводить. А вот как по этой информации progress bar строить... Но это уже не моя проблема.

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

Чтобы построить общий прогрессбар, достаточно.

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

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

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

и прощай производительность.

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