Представлена (http://permalink.gmane.org/gmane.org.fsf.announce/2343) новая стабильная версия набора базовых системных утилит GNU Coreutils 8.24, в состав которого входят такие программы, как sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln, ls и т.д.
Основные новшества:
- В утилиту chroot добавлен флаг "--skip-chdir", при указании которого рабочая директория не меняется на "/" после выполнения вызова chroot;
- В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;
- В утилите numfmt появилась возможность обработки нескольких полей, которые указываются в виде диапазона по аналогии с утилитой cut;
- В утилиту split добавлена опция "--separator" для выбора символа-разделителя записей, отличного от символа перевода строки;
- В stty добавлена возможность установки опции "extproc";- В утилите tee появилась опця "--output-error" для обработки ошибок и управления неименованными каналами;
- В cp, install и mv обеспечена поддержка замены нулевых областей в файлов на пустые области на уровне ФС.
- В cp увеличена эффективность чтения файлов с пустыми областями, если копирование осуществляется не в файл;
- В mv добавлена проверка возможности выполнения вызова reflink для эффективного перемещения файлов между разделами Btrfs вместо обычного копирования;
- Увеличена эффективность обработки коротких строк при выполнении
"wc -l".
URL: http://permalink.gmane.org/gmane.org.fsf.announce/2343
Новость: http://www.opennet.me/opennews/art.shtml?num=42563
>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;Оперативненько, не прошло и полвека.
ну
while killall -USR1 dd; do sleep 1; done
никто не отменял, кстате интересно на сколько долей процента проверка необходимости обновлять статус и его обновление снижает производительность, в konsole c композитом лишние букафки выдаваемые на экран тормозят проги в разы.
Если аккуратно сделано - то ни на сколько. Отдельный поток, к примеру. Да и в любом случае - раз в секунду - не значимо совершенно. Не говоря о том, что это всё же опция. В общем, давно пора было.
Отдельный поток мб, но переносимость на встраиваемые системы пострадает, а колбэк на сигнал тривиально даже там.
Так сигнал никто и не отбирает. Что до встраиваемых платформ - если там даже потоков нет, то надо busybox или подобное использовать, а не coreutils. впрочем, раз в секунду как строку не выводи - производительность не потеряешь.
во фряхе Ctrl+T
> while killall -USR1 dd; do sleep 1; done никто не отменял,...только вот печатать все это как-то дольше получается чем 1 ключ командлайна. Вообще, для меня загадка какой инопланетянин придумал это делать так. Это самый ректальный способ вывода прогресса который я встречал.
> Вообще, для меня загадка какой инопланетянин придумал это делать так. Это
> самый ректальный способ вывода прогресса который я встречал.Далекий 97 год.
https://github.com/coreutils/coreutils/commit/5a74e8ae4ef3f5...
+#ifndef SIGINFO
+# define SIGINFO SIGUSR1
+#endif
Правда, SIGINFO посылается простым CTRL-Т, в отличии от ...
>>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;
> Оперативненько, не прошло и полвека.Нафиг не нужно, есть же pv:
dd if=/dev/sda | pv --size $(blockdev --getsize64 /dev/sda) | dd of=/dev/sdb
Передавать данные через два пайпа ради этого? В идеале dd if=/dev/sda of=/dev/sdb должен sendfile(2) делать.
pv /dev/sda | dd of=/dev/sdb работает .. сразу прогресс бар и время и вся лабуда отображается
в ddrescue уже давно всё есть)
и как вы его поставите, если доступа в инет нет, а он по умолчанию, в отличии от dd, не установлен, по крайней мере в дистрах и Live-CD, с которыми я сталкивался.
> в ddrescue уже давно всё есть)Тогда я за dc3dd, если что.
>> в ddrescue уже давно всё есть)
> Тогда я за dc3dd, если что.Если что, это всё есть в altlinux.org/rescue :)
> в ddrescue уже давно всё есть)Только он по дефолту гадит файлом битмапов и вообще немного не для этого.
Зачем вообще дэдэ нужен?
pv </dev/sda >/dev/sdb
> pv /dev/sda | dd of=/dev/sdb работает .. сразу прогресс бар и время
> и вся лабуда отображаетсяИ куда тут впихнуть conv=noerror,sync при случае?
Где ты у ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
видишь прогрессбар? Ты либо sendfile используй, либо процентики смотри.
Да ну, это примитивно, это ретроградство, это прошлый век! Надо выводить на вебморду, с танцующими понями и котиками! Переписать, встроить веб-сервер, базу данных, отправку статистики в Твиттер, Фейсбук и Гуглплюс. И конечно же, включить в системд! Как раз будет повод версию апнуть еще на одну циферку.
> Отправлено PoetteringЯ тебя где-то видел...
>>В утилиту dd добавлен отладочный уровень "status=progress"
> Оперативненько, не прошло и полвека.Так давно уже pv(1).
PS: ага, хорошо, что про полезную утилитку много кто знает :)
> PS: ага, хорошо, что про полезную утилитку много кто знает :)А Михаил всегда с удовольствием расскажет нам как правильно закручивать гвозди отверткой.
>> PS: ага, хорошо, что про полезную утилитку много кто знает :)
> А Михаил всегда с удовольствием расскажет нам как правильно
> закручивать гвозди отверткой.Если Вам требуется именно закрутить гвоздь отвёрткой, для этого стоит выбрать подходящий по запасам экземпляр, на шляпке сделать продольный надрез пилой по металлу и нарезать резьбу с подходящим шагом -- собственно, для этого и предназначена отдельная утилита.
А dd(1) ETA не показывает и кофе не варит, сущая правда.
PS: вообще-то не понял бухтежа, вполне хорошая утилитка, регулярнейшим образом пригождается при записи исошек на флэшки.
> и нарезать резьбу с подходящим шагом -- собственно, для этого и
> предназначена отдельная утилита.Вот-вот, я именно об этом. А можно вообще переплавить этот гвоздь: углерода досыпать, фому заготовки поудачнее сделать, закалку организовать. Будет не сильно хуже магазинного самореза, если постараться.
А нормальный человек - таки пойдет и просто возьмет шуруп. Который быстренько вкрутит и забудет об этом. Так быстрее и результативнее.
> А dd(1) ETA не показывает и кофе не варит, сущая правда.
Ну а мне вот видится не очень оптимальным сношаться с переплавкой стали вместо того чтобы взять готовый шуруп. В любом уважающем себя доме - кучка шурупов должна была болтаться "про запас" (ну а в программе - точно так же, но с фичами). И заявы про bloat и занимаемое место идут лесом на фоне единственной печки для плавки стали, которая всяко крупнее десятка шурупов.
Это я к тому что идея пайпить ...цать гигабайтов через левые тулзы мне что-то не прикольна в плане оверхеда по ресурсам. Оверхед от пары мелких плюшек типа отрисовки прогресса - зело меньше.
> PS: вообще-то не понял бухтежа, вполне хорошая утилитка,
А бухтеж - по поводу того что предлагается гонять 100500 гигазов через всякие там пайпы и чуть не полдюжины программ. И все бы ничего, но нагрузка на систему может увеличиться, а скорость операций - уменьшиться. На обслуживание пайпа тоже какие-то ресурсы тратятся.
А когда я хотел прогресс операций - это обычно таки большой объем данных был, по поводу чего операция и была длительная.
> регулярнейшим образом пригождается при записи исошек на флэшки.
Остап знал over 9000 способов записать флешки. Можно даже миднайтом скопировать файлов в /dev/чтотамеще. Даже работает. С прогрессом в человеческом виде и прочая. И все это прекрасно. Но раз уж dd есть везде и умеет рисовать прогресс, будет намного менее ректально если он сможет это делать не только по инопланетянскому критерию sigusr1 но и по каким-то более человеческим. И это называется улучшение юзабилити программы. А в ответ что мы видим? Бряцание скиллами по обработке металлов с аргументом "могу сделать х..венький шуруп из гвоздя". Мне кажется что скиллам по обработке металла можно было бы найти и какое-то более дельное и более убедительное для окружающих применение, коли такие скиллы есть.
>> Если Вам требуется именно [...]
> А нормальный человек - таки пойдет и просто возьмет шуруп.Так и я об этом. :)
> Это я к тому что идея пайпить ...цать гигабайтов через левые тулзы
> мне что-то не прикольна в плане оверхеда по ресурсам. Оверхед от
> пары мелких плюшек типа отрисовки прогресса - зело меньше.Вы, как порой бывает, ведёте тяжёлые позиционные бои с калиткой в чистом поле -- и мелкие плюшки хороши, и тулза, которая показывает, что осталось примерно пять минут, тоже хороша (особенно когда < > и без | работают).
>> PS: вообще-то не понял бухтежа, вполне хорошая утилитка,
> А бухтеж - по поводу того что предлагается гонять 100500 гигазов через
> всякие там пайпы и чуть не полдюжины программ.Ну некоторые вон cat | grep предлагают -- что ж теперь, обвинять grep в этом | ?
> Остап знал over 9000 способов записать флешки. Можно даже миднайтом скопировать
> файлов в /dev/чтотамеще. Даже работает. С прогрессом в человеческом виде и прочая.
> И все это прекрасно.Не, это как раз жутко неудобно: огромное кол-во лишнего кода под рутом (либо менять права на /dev/sdX), полноэкранная софтина вместо строчки в шелльной истории... Т.е. можно, но не для постоянного использования. Применительно к выбранной аналогии -- тот самый гвоздобойный мелкоскоп. :)
> И это называется улучшение юзабилити программы.
Вот на этом и предлагаю согласиться да закрыть вопрос :)
Как раз таки пол века и прошло.
dcfldd в помощь.
>В mv добавлена проверка возможности выполнения вызова reflink для эффективного >перемещения файлов между разделами Btrfs вместо обычного копирования;офигенно! очень нужно, а то прихолось делать cp --reflink-always и потом удалять на источнике.
ну и прогресс бар у dd тоже нужная вещь.еще б дождаться когда пакет будет, и чтоб его можно было в текущий lts ubuntu server воткнуть..
>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;не unixway'но. есть же pv/cv.
> не unixway'но. есть же pv/cv.Если юниксвэй означает залезание в ластах и противогазе на фонарный столб, вместо того чтобы сделать наконце программу не через зад - может, вы таки и свалите в эти ваши юниксы? Там вам будет самое место. А GNU == Gnu is Not Unix, поэтому они как-нибудь могут позволить и не копировать все бестолковости 1 в 1.
>GNU == Gnu is Not Unix, поэтому они как-нибудь могут позволить и не копировать все бестолковостиБери выше! Они могут сами творить бестолковости - системдя тому пример! :)
Ты что считаешь что systemd создавали GNU?... x_X
>Ты что считаешь что systemd создавали GNU?... x_XЯ в сортиах ... в их сортах не разбираюсь :)
Могу спросить по другому - этот програмистский шЫдэвр есть ещё хоть где то кроме GNU\Linux? Ну дык и чО ты тут засуетилси?
> Бери выше! Они могут сами творить бестолковости - системдя тому пример! :)А системд, между прочим, когда я облажался в юните - написал мне в свой journalctl'овский лог и вывод програмы и что програма завершилась с ошибкой и статус юнита вывесил в зафэйленый. Сразу понятно где лажа. А в sysv init чтобы такое случилось - надо сначала самому напиать половину логгинга и анализа кодов возврата. Вот такая вот небольшая разница...
> А в sysv init чтобы такое случилось -...достаточно сделать /etc/init.d/сервис start (что вообще-то при тестировании делается) и если непонятно сразу же, так запустить при помощи sh -x...
Тебе не доставало прогрессбара и ты делал все через задницу? Или твой пассаж о том что необходимо в каждой утилите дублировать функционал, вместо того, чтоб вынести в отдельную утилиту, умеющую взаимодействовать со всеми?
Когда функционал тривиален - не грех и сдублировать для часто используемого случая. Это если бы туда начали совать, например, формартные строки, ключи для того, чтобы задать интфервал или ещё что-то подобное - я бы первый возмутился. А на один ключик, один таймер и один printf - глупо возмущаться. Возни мало, удобства много.
>А на один ключик, один таймер и один printfмелочи нагромождаются. По мне, так синдром плюшкина. Кому раньше это нужно было/не хватало - использовали pv/cv. А кому не надо было, или изредка мелькала мысль, или первый раз в консоли и изучают (--help'ы) -- появилось утешение.
Ну вот когда/если таких мелочей накопится столько, что от них будут какие-то реальные проблемы - кто-нибудь почистит - или в виде форка, или в самих coreutils - не важно. И оставит фичи, нужные на тот момент. Но подозреваю, что в coreutils таких проблем не будет никогда.Что до меня - я полагаю, что принцип "простое должно быть простым, а сложное - выполнимым" здесь реализован совершенно осмысленно. И что он важнее, чем идеальная ортогональность.
> Ну вот когда/если таких мелочей накопится столько, что от них будут какие-то
> реальные проблемыну да, на одни и те же грабли год за годом. Потом обнаруживают вроде такого http://www.opennet.me/opennews/art.shtml?num=40779 и воют о нормальной методологии разработки, верификации, и т.д.
> Но подозреваю, что в coreutils таких проблем не будет никогда.
такие проблемы уже есть, и не только в coreutils.
> Что до меня - я полагаю, что принцип "простое должно быть простым,
> а сложное - выполнимым" здесь реализован совершенно осмысленно.ууууу... проехали. Гиблое дело, нам друг друга не понять.
> Тебе не доставало прогрессбара и ты делал все через задницу?Да, ты знаешь, мне бы не помешал прогресс в dd вызываемый ключом командлайна а не тем ректальным методом с sigusr1. Потому что для того ректального метода - в командлайне печатать надо многовато.
Ну то-есть на своем компе можно алиасы вбить и прочее. А если компов 20 - то чего? На всех вбивать алиасы? Это уже как-то совсем ректально и хвост виляет собакой.
> пассаж о том что необходимо в каждой утилите дублировать функционал,
В dd функциональность показа прогресса была, мягко говоря, давно. Только делается очень уж ректально - отсылом dd сигнала SIGUSR1. По поводу чего я нахожу очень логичным что подобную фичу можно вызывать и как-то менее ректально, как то - ключом командлайна.
> вместо того, чтоб вынести в отдельную утилиту, умеющую взаимодействовать со всеми?
Вот ща я буду гонять 200-гиговый образ диска (по поводу чего меня прогресс опеации и интересовал) через полдюжину утилит. Еще вдуй 200 гигз в дрянь на питоне, чтобы операция тормознулась раз в пять - тогда будет решение истинно в твоем духе.
>А GNU == Gnu is Not UnixПовторяй как мантру, непонимая смысла этого акронима.
> Если юниксвэй означает залезаниеТ.е. очередной диванный эксперт, не знающий основ, но мнение имеющий?
http://www.faqs.org/docs/artu/ch01s06.html
> This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.Учитывая тогдашние реалии, можно заменить "text stream" на что-то более абстрактное (прям как в оригинальном высказывании):
> (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
> program. Don't clutter output with extraneous information.И все бы ничего. Только у меня dd обычно оперирует многогигабайтными образами дисков и лишний раз это куда-то пайпить я труба шатал. Потому что пайпить 100500 гигз только ради того чтобы прогресс видеть - это крeтинизм в терминальной стадии. С точки зрения системной инженерии, иррелевантно к блеяниям сцаных скриптокидозникв про вэйность и что там еще. Пусть они таким извращением занимаются без меня. А меня не прет идея пайпить 100500 гигз данных лишний раз без серьезной на то нужды.
Да, мне нравятся оптимальные и эффективные решения. Даже если это и не всегда расово верно. Вот такой вот я нехороший.
> И все бы ничего. Только у меня dd обычно оперирует многогигабайтными образами
> дисков и лишний раз это куда-то пайпить я труба шатал.Жмем CTRL + T => SIGINFO => всякая инфа о том, сколько, куда и откуда и все такое -- прям в процессе копирования!
Ух ты! Никакой магии -- и вообще, слишком просто!1 Не юниксвей (в понимании экспертов опеннета), однозначно! Хотя, возможно, еще совсем немного сыровато:
https://github.com/coreutils/coreutils/commit/5a74e8ae4ef3f5...
И опять же, да -- это вполне удобно и работает! Просто жмешь CTRL-Т, без всяких pv и иных извратов -- как и было задуманно.
Правда, те, кто вопил, что SIGINFO старперно и ненужно и заменил SIGINFO на SIGUSR1 -- ну, вот им не повезло, да. Пришлось страдать, извращаться и ждать 18 лет, пока не запилили опцию.> Потому что пайпить 100500 гигз только ради того чтобы прогресс видеть -
> это крeтинизм в терминальной стадии.А с этим, как бы, никто не спорил. Любители создавать себе проблемы на ровном месте и храбро их преодолевать -- могут и будут продолжать страдать дальше =)
> С точки зрения системной инженерии, иррелевантно
> к блеяниям сцаных скриптокидозникв про вэйность и что там еще.Классика опеннета -- ананим записал M.D McIlroy-я в скриптокидизы :) Ну да, он же придумал пайпы, а пайпы, как известно, используются скриптами!
> Да, мне нравится порассуждать на опеннете о том и о сем. Даже если это и не
> всегда расово верно. Вот такой вот я нехороший д'Артаньянfixed
Объясните, а как тут поможет pv ? В `dd` ведь нету пайпов, оно исполняется одной командой.
Как вы используете pv для целей слежения за `dd` ?P.S. или вы не применяете "of" (output file) а вместо этого добавляете лишний пайп?
dd if=... | pv > myOutput
скорость от этого по факту не понизится? А то ведь у dd есть разные опции вида "bs" (block size), я не понимаю как они выживут при pipe-овании. С виду не выживут, хотя бы от того что в дефолтном линуксе не очень большой размер пайп-буфера.
> скорость от этого по факту не понизится? А то ведь у dd
> есть разные опции вида "bs" (block size), я не понимаю как
> они выживут при pipe-овании.bs от dd "при пайпах" выживут: в пайп он будет писать и из него читать указанными блоками.
И у pv тоже есть -B = --buffer-size. При копировании сотен мегабайт или даже если и когда нужен прогресс или ETA, пайп, как таковой совешенно неразличим на фоне дискового io[wait]. Да, конечно, _надо_ ставить буфера/блоки по 10-100Мб (и dd, и pv, если они в пайте), а не 1К."Замедлению при пайпах"? Вы просто не умеете их готовить?
ЗЫЖ Пока не спросили, "sed быстрее awk-а" тоже никак не относится к преподносимой нам здесь выдуманной проблеме "замедления при пайпах".
Я вроде не писал букв "замедление при пайпах", не надо ставить кавычки.В остальном -- если вы проверяли, то ОК, готов поверить. Если это не так то всё равно кто-нибудь (надеюсь) возразит.
P.S. И пайп всё-таки имеет собственный размер буфера, и блокировки записи/чтения он тоже делает:
> If a process attempts to write to a full pipe (see below), then write(2) blocks until sufficient data has been read from the pipe to allow the write to complete.
использую cv.
В вин7 с флешки фат32 на нтфс 17,3мбс в дебиане 15,9мбс на ext4 копирует
По факту
> В вин7 с флешки фат32 на нтфс 17,3мбс в дебиане 15,9мбс на
> ext4 копирует По фактуКрутой замер. Ни методики, ни результатов.
Нападки на konsole - ЛПП. В этом очень легко убедиться измерив скорость вывода в konsole, XTerm, etc., например, командой:
time seq -f 'teeeeeeeeeeeeeeeeeeeeeeeeeeeeeest %g' 100000так вот, проверьте и уд{и|а}витесь
А нет ли в них какого-нибудь фатального недостатка?
> А нет ли в них какого-нибудь фатального недостатка?Они слишком "завязаны" на шелл. Петя, переписать в 5 строчек!!
> А нет ли в них какого-нибудь фатального недостатка?А что, ddd - это звучит :)
systemd-ddd :)
lsd тоже
> А что, ddd - это звучит :)Причём уже давно, но в совсем другой тональности: http://pkgs.org/search/ddd?type=srcfilename :)
http://www.opennet.me/opennews/art.shtml?num=42198
> http:/opennews/art.shtml?num=42198А потеринг при чём? А-а-а... гоникс. Лёня, да, гонщик.