очевидно нуждающихся

Для кого очевидно?

а нафига тебе в скриптах прогрессбары?

А в чем глубинный смысл прогресс-бара в скриптах?

Потому что для подсчета времени выполнения cp, mv, rm нужна куча времени. Опять же неточно, все прогресс-бары в 2014 врут безбожно. Виндузятники мужественно это терпят, а линуксоиды прячут по привычке голову в песок из ненужно.

В виндах copy и move тоже не имеют прогрессбара.

Так ими никто и не пользуется, а прогресс-бары доходят до 100% и там тупят еще столько же. Проблема вообще не разрешима в ФМ, если только на уровне файловой системы писать атрибутом время копирования, да и то диск имеет разную скорость на разных участках, вообщем на глаз или «ненужно». Зы. Плюс другая нагрузка совершенно непредсказуемая.

Необязательно расчитывать время. Информация о том сколько байт уже скопировано/перемещено и полный размер файла доступны копирующей программе. Этого достаточно что-бы сделать прогресс бар или «54/123 MB». To что на самом деле оно возможно запишеся через некоторое время после завершения копирования, не забота копирующей программы. Прогресс бар/счетчик показывает текущий прогресс выполнения конкретной программы.

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

Ну предложи разрабам патчик, который будет включать это.

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

От добавления, скажем, опции --show-progress-bar хуже никому не станет. В скриптах действительно не всегда нужно.

А какая разница будет врать в секундах или мегабайтах. Есть pv для одного файла, есть где надо развлечь пользователя и прогресс-бары, имхо всё есть и ничего принципиально нельзя поменять. Без индикации тупо быстрее.

К примеру, в случае c dd rsync ничем не поможет.

Кому это очевидно?

Hint: в пресловутом unix-way команды репортят в stdout/stderr только при ошибках. Нет репорта — нет ошибки. Progressbar в эту философию не вписывается.

Потому что юниксвей - программа пишет в stdout/stderr только тогда, когда ей нужно сообщить что-то важное. Информация о прогрессе таковой не является.

Если тебе нужен прогрессбар, для этого есть отдельная утилита pv

dd умеет сам репотить (SIGUSR1 и/или ^T — если в tty включён «status»)

Не говорите ему о pv

^^

Потому, что так устроен терминал в линуксах: есть stdout и stderr, ни один из них не подходит, чтобы туда на постоянной основе запихивать твой прогрессбар (но ты можешь костылять для интерактивного использования что угодно). В termkit были движения в сторону стандартного интерфейса, отделённого от stdout/stderr, но он не взлетел по очевидным причинам.

команды репортят в stdout/stderr только при ошибках. Нет репорта — нет ошибки.

Это скорее для stderr верно. Иначе, какой тогда смысл в stdout? Но прогрессбар не нужен, да :)

чем тебя не устраивает «watch du -hs /somepath»?

wget тоже? curl?

Это же GNU-изгои, что с них брать, кроме анализа colors, да и то в ANSI?. Кошеный ftp так себя не ведёт.

Используй файловый менеджер

15 лет назад при переходе с FreeBSD на линукс я страдал от того, что в linux в ftp клиенте прогрессбара нет. А в BSD есть!

Вот вроде и модератор, а идиот.

лорчую

Таки ведёт. Ладно, вбос провалился. =)

А вот в plan9 есть унифицированный progress bar.

ref: http://www.plan9.bell-labs.com/wiki/plan9/unix_to_plan_9_command_translation/

возьми@напиши

это дело максимум выходных

Люди не только по одному файлы копируют, знаешь. Иногда каталоги с миллионами файлов. Предлагаешь пройтись сначала рекурсивно и подолбить stat чтобы посчитать суммарный размер?

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

Я думаю, причина того, что в линуксе нет прогрессбаров в cli, в том же, почему вместо переписывания ifconfig'а (даже виндовый ipconfig на него похож!) запилили свой ip2 с блекджеком и весёлыми дамами.

Ну предложи разрабам патчик, который будет включать это.

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

чем тебя не устраивает «watch du -hs /somepath»?

Скорость может просесть. Зависит конечно от железа, количества, объема но все равно не есть хорошо :(

https://github.com/Xfennec/cv

Бебебе 2014 год

Лорчую. А ещё в 2014 до сих пор не научились полностью совмещать трей и панель задач в одну панель.

Я не поверю, что до сих пор никто не пытался. Результата нет => не приняли в апстрим. Мне интересно почему.

Ну вообще это не аргумент, так как запуск из скрипта легко определяется стандартной функцией isatty.

Иногда каталоги с миллионами файлов.

ССЗБ. Нужно было продумывать способ хранения данных.

Потому что идея коммандлайновых утилит в том, чтобы их вывод могли парсить (а ввод — генерировать) другие утилиты. Прогрессбар моментально усложнит парсинг.

Гм. А если этот каталог — не твой? Если тебе его на флэшке принесли?

Не говоря уже о том, что миллион файлов — это всего-то шесть уровней вложенности по десять файлов в каждом каталоге.

watch du -hs /somepath

класс, спасибо :)

Иногда каталоги с миллионами файлов.

ССЗБ. Нужно было продумывать способ хранения данных.

Ты апоротый наркоман. Бекап делал когда-нибудь?

Бекап ЧЕГО? Всей ФС? Нет, и не нужно.

файлопомойки например

$ cd /run/media/stil/Backup/storage/
$ du -h 2014-12-02.tar 
444G    2014-12-02.tar
$

Файлопомойки? К счастью нет. Но потому ее и назвали помойкой.

Скорость может просесть.

Если у тебя IDE 10летней давности :)

Первый подсчет размера занимает время, потом инфа выдается быстро.

Не похоже, что du, каждый раз перещитывает размер всей директории, по моему оно считает только разницу.

у тебя IDE 10летней давности

Нет. SSD само собой не рассматриваем.

Не похоже, что du, каждый раз перещитывает размер всей директории, по моему оно считает только разницу.

В предложеном тобой варианте тормозить будет не du сам по себе, а скорость перемещения перемещаемого. HDD не особо пригоден к деланию несколько дел разом.

Почему тот же прогресс-бар до сих пор не является частью функционала в очевидно нуждающихся в нём утилитах (cp, mv, rm, ...)

потому что не нужно. система многозадачная, поэтому можно делать что-то другое пока копируется.

А на окончание копирования можно поставить извещение, если есть желание.

Не похоже, что du, каждый раз перещитывает размер всей директории, по моему оно считает только разницу.

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

Нет. SSD само собой не рассматриваем.

У меня 2 рейда, из красных и зеленых WD.

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

Можно «watch -n 15 du -hs /somepath» если лагает.

Кстати, прогресс бар все равно должен подсчитывать сколько скопировалось. Как он это будет делать не обращаясь к диску?