mv, cp, dd etc с прогресс-баром

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

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

Тогда используй mc :)

Ок, посыпаю голову пеплом, в свое время искал — не нашел, а ответ на SO убедил меня в том, что такой опции нет. Мне очень стыдно.

Ты не один такой.)

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

Есть такая штука, логика.

О какой концепции идёт речь?

UNIX, какая же ещё в данном контексте?

Есть такая штука, логика.

Тогда продемонстрируй ту логику, которой ты руководствовался перед достижением такого вывода.

UNIX, какая же ещё в данном контексте?

С каких пор Linux и утилиты базовой системы соответствуют стандартам UNIX?

Тогда продемонстрируй ту логику, которой ты руководствовался перед достижением такого вывода.

У тебя какие-то проблемы с логикой?

С каких пор Linux и утилиты базовой системы соответствуют стандартам UNIX?

Во-первых, при чем тут Linux?

Во-вторых, встречный вопрос: с каких это пор проект GNU стал POSIX-несовместимым?

У тебя какие-то проблемы с логикой?

Нет. А у тебя?

Во-первых, при чем тут Linux?

При том что я использую ОС на его основе.

Во-вторых, встречный вопрос: с каких это пор проект GNU стал POSIX-несовместимым?

Это который своё работающее ядро родить не смог и который наезжает на создателя Linux из-за названия?

стандарты UNIX

GNU is Not Unix

Лол.

с каких это пор проект GNU стал POSIX-несовместимым?

Например:

The GNU core utilities support long options as parameters to the commands, as well as (unless the POSIXLY_CORRECT environment variable is set) the relaxed convention allowing options even after the regular arguments. Note that this environment variable enables a different functionality in BSD.

Double hyphen-minuses are also sometimes used to prefix «long options» where more descriptive option names are used. This is a common feature of GNU software.

Нет. А у тебя?

Чуть позже к этому вернемся.

При том что я использую ОС на его основе.

Эталонный автор ЕОТ - и прочих тредов в толксах. Что, эта фраза может оправдать любой тупняк на ЛОР?

Это который своё работающее ядро родить не смог и который наезжает на создателя Linux из-за названия?

Ещё раз повторяю вопрос: с каких пор проект GNU стал POSIX-несовместимым?

GNU is Not Unix

Лол.

Лолчто? Уточни, а то может показаться, что ты само семейство UNIX отождествляешь с набором стандартов UNIX. Это так, к вопросу о логике.

Утилиты GNU поддерживают длинные опции, в дополнение к коротким, как предписано стандартом. Как расширение функционала делает их несовместимыми?

Эталонный автор ЕОТ - и прочих тредов в толксах.

Щито? Ты меня с кем-то путаешь.

Ещё раз повторяю вопрос: с каких пор проект GNU стал POSIX-несовместимым?

С самого начала он был частично несовместимым. Вот ещё:

POSIX mandates 512-byte block sizes for the df and du utilities, reflecting the default size of blocks on disks. When Richard Stallman and the GNU team were implementing POSIX for the GNU operating system, they objected to this on the grounds that most people think in terms of 1024 byte (or 1 KiB) blocks. The environment variable POSIXLY_CORRECT was introduced to allow the user to force the standards-compliant behaviour. The variable name POSIX_ME_HARDER was also discussed. The variable POSIXLY_CORRECT is now also used for a number of other behaviour quirks, where “POSIX and common sense disagree”.

Как расширение функционала делает их несовместимыми?

Возвращаемся к первоначальному вопросу — как расширение функционала сабжевых утилит делает их несовместимыми с концепцией UNIX?

Судя по тому, что часть моих вопросов ты проигнорил, вопрос с логикой снимаю.

С самого начала он был частично несовместимым. Вот ещё:

В твоей же цитате есть опровержение твоего утверждения:

The environment variable POSIXLY_CORRECT was introduced to allow the user to force the standards-compliant behaviour

Возвращаемся к первоначальному вопросу — как расширение функционала сабжевых утилит делает их несовместимыми с концепцией UNIX?

Подмена понятий. Твое расширение нарушает принцип «одна программа - одно действие», в отличие от упомянутого размера блока.

The environment variable POSIXLY_CORRECT was introduced to allow the user to force the standards-compliant behaviour

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

Подмена понятий.

Обоснуй.

Твое расширение нарушает принцип «одна программа - одно действие»

4.2, действие только одно — копирование файлов/каталогов. Или у тебя что-то с логикой?

Кстати, можно же сделать костыль, следящий за тем, сколько времени происходит подсчёт размеров файлов. Если с момента вызова команды прошло больше N времени — прерывать подсчёт и начинать копирование.

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

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

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

Эпично. Внушает. Так определись, совместимый или нет? Более того, ты ухитрился перепутать концепцию UNIX, о которой шла речь и стандарт POSIX.

Обоснуй.

От обоснуя слышу. Ты объединил в расширение функционала два разных типа - нарушающий концепцию UNIX и не нарушающий. Либо ты не знаком с логикой и её понятиями, либо наоборот, слишком хорошо знаком.

4.2, действие только одно — копирование файлов/каталогов. Или у тебя что-то с логикой?

А у тебя с арифметикой как? Показ прогресс-бара это тоже действие. cp/mv как раз одно действие и выполняет, а ты предлагаешь вшить туда свистелок и перделок. Да, это полезные свистелки, но их можно прикрутить сбоку в рамках концепции одной утилитой, которая и показывает прогресс операции, и только его.

А у тебя с арифметикой как? Показ прогресс-бара это тоже действие. cp/mv как раз одно действие и выполняет, а ты предлагаешь вшить туда свистелок и перделок

По твоей логике в mv, cp и rm свистелки и перделки уже давно есть. Вызываются опцией -v. Поэтому утверждение

cp/mv как раз одно действие и выполняет

— 4.2. И это я ещё не вспомнил про опцию -i.

но их можно прикрутить сбоку в рамках концепции одной утилитой

Какой именно?

Так определись, совместимый или нет?

Нет конечно, иначе костыли типа POSIXLY_CORRECT не внедрялись бы.

ты ухитрился перепутать концепцию UNIX, о которой шла речь и стандарт POSIX

Нет, про POSIX первым написал ты.

Нет конечно

Если быть более точным — он частично совместимый.

Вызываются опцией -v

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

-v требует ничтожно малого кода, всего лишь вывод имени на stdout, а полезность для конвеерных работ очень высока. Прогрессбар - требует большего кода, усложняет примитивные утилиты, не всем нужно, и просто нерационально запихивать в каждое приложение опциональный прогрессбар. Дублировать в каждую core-утилиту. А что если нужно комбинировать утилиты, кодировать/декодировать через конвеер и передавать/копировать куда-то? Из какой программы полезен будет прогрессбар? Не из какой, тут нужно другое время. Pv создан именно для этой цели: быть прогрессбаром для всего чего захочешь. Он может показывать общее время, и время конкретной операции независимо от того, поддерживает программа прогрессбар или нет. Просто используй его, и не выёбывайся.

-v требует ничтожно малого кода

Но ведь действий-то уже как минимум два, в отличие от того что утверждал eagleivg.

Прогрессбар - требует большего кода, усложняет примитивные утилиты

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

не всем нужно

Как и опции -v, -i и ещё половина других.

И просто нерационально запихивать в каждое приложение опциональный прогрессбар

А вынести в библиотеку?

Просто используй его, и не выёбывайся

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

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

Какой именно?

Что какой?

Нет, про POSIX первым написал ты.

Отнюдь, вопрос про стандарт поднял ты, см. здесь:

С каких пор Linux и утилиты базовой системы соответствуют стандартам UNIX?

Ты намеренно путаешь семейство UNIX, стандарты POSIX и концепцию UNIX, или у тебя в голове такая каша?

Прогрессбар не передашь никуда

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

-i - сомнительная фишка

Расскажи это автору и пользователям bumblebee, которые остались без /usr. То, что тебе это не нужно — не значит что не нужно остальным.

Что какой?

Какой утилитой.

Отнюдь, вопрос про стандарт поднял ты, см. здесь:

Я ничего не говорил о конкретных стандартах, ты сам это додумал.

семейство UNIX, стандарты POSIX

См. выше.

концепцию UNIX

Стандарты напрямую опираются на концепции.

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

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

Расскажи это автору и пользователям bumblebee, которые остались без /usr. .

На редкость неудачный пример. Чем поможет интерактивный режим в установочном скрипте?

То, что тебе это не нужно — не значит что не нужно остальным.

Я поэтому и сказал «админ локалхоста»

Я ничего не говорил о конкретных стандартах, ты сам это додумал.

Хорошо, по пунктам:

h578b1bde: О какой концепции идёт речь?

eagleivg: UNIX, какая же ещё в данном контексте?

h578b1bde: С каких пор Linux и утилиты базовой системы соответствуют стандартам UNIX?

То что ты не упомянул конкретно POSIX, уже не важно, каким макаром концепция у тебя в голове преобразовалась в стандарты - вот в чём вопрос?

Стандарты напрямую опираются на концепции.

Это не значит, что между стандартом и концепцией можно ставить знак равенства. Можно написать стандарт, который основывается на концепции UNIX и при этом не будет являться POSIX-ом.

Какой утилитой.

pv

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

Если вызвать копирование с опцией -i, случится страшное — поломаются конвееры из команд, которые его слушают. Но ведь никто не заставляет вызывать его с этой опцией, верно?

Чем поможет интерактивный режим в установочном скрипте?

Это пример одной маленькой, но разрушительной опечатки. Ты при работе в консоли никогда опечаток не делал?

каким макаром концепция у тебя в голове преобразовалась в стандарты - вот в чём вопрос?

Стандарты разрабатываются в соответствии с выбранной концепцией. При отклонении от стандартов можно отойти и от концепции.

Можно написать стандарт, который основывается на концепции UNIX и при этом не будет являться POSIX-ом.

Я и не утверждал что нельзя. Хорошо, другой пример. Возьмём концепцию UNIX „всё есть файл” и попытаемся найти файлы сетевых интерфейсов в Linux. Приходим к выводу что Linux не соответствует принципам UNIX.

Да, это полезные свистелки, но их можно прикрутить сбоку в рамках концепции одной утилитой, которая и показывает прогресс операции, и только его
pv

Нет, нельзя, т.к. эта утилита не будет работать с cp -r.

Можно накостылить что-то типа:

tar cpf - /source/path | pv | tar xpf - -C /dest/path

Но надо постараться, что бы иметь гибкость cp с его wild-card. Поэтому, решение с cp --progress было бы идеально :)

Еще раз cv