私は尋ねません。どのように。私はすでにpv
同じオプションを知っていますrsync -P
。
聞きたいなぜcp
少なくとも表示で進行状況バーを実装しませんか?
答え1
Unixツールの伝統は、問題が発生した場合にのみメッセージを表示することです。ここにはデザイン的な理由と実用的な理由の両方があると思います。問題が発生したときにエラーメッセージが表示され、実際の情報ではなくメッセージにエラーが埋まらないように設計されています。実用的な理由は、UNIXの初期にはまだテレタイププライターつまり、プログラムの出力は紙に印刷され、進行状況バーは印刷したくありません。
理由が何であれ、有用なメッセージだけを表示する伝統はUNIXの世界に深く根ざしています。最新のツールには時々進行状況バーが表示されます。 rsyncの場合、主な動機はrsyncが通常ローカルディスクよりもはるかに脆弱なネットワークを介して行われるため、進行状況バーがより便利です。同じ推論がwgetにも当てはまります。
答え2
UNIXの世界では、すべてのツールは仕事をうまく実行するように設計されています。他の同様のツールがすでに進捗状況を出力するのに進捗状況を心配しているのはなぜですかcp
?pv
同様に、なぜそんなに多くのプログラムがページなしでコンテンツを画面にダンプするのですか?more
(または)などの作業に適したツールがすでにあるためですless
。ファイルを編集する必要があるほとんどのプログラムがエディタを提供せずにアウトソーシングするのはなぜですか$EDITOR
?これにより、各人は自分が行うように設計された1つのタスクのみを完了できますが、ユーザーは自分の好みのエディタを使用してすべてのタスクを完了できるからです。
しかし、ほとんどのシェルプログラムは、出力を別のシェルプログラムにパイプするように設計されています。彼らが提供できる唯一の出力は、チェーンの次のコマンドで解析するのに役立ちます。同様のプログラムをcp
スクリプトで使用するか、端末で手動で使用することができるため、出力は主に終了コードと失敗したり、成功したファイルのリストを中心に行われます。
目的の効果を得るには、常にツールの組み合わせを使用する必要があります。
答え3
これは、cpにプログレスバーオプションを追加することを承認し、反対する非主流の1つです。これに対する主な主張は、進捗状況について知りたいことを事前に知らないかもしれないということです。この目的のためにBSDでCtrl-T / SIGINFOを使用することができます。GNU / Linuxプラットフォームで利用できる場合は、cpでプログレスバーロジックをトリガーする必要がある理由がいくつかあります。その間のより一般的な解決策は、別々のツールを使用することです。これCoreutilsプログレスビューア(progress
、以前はとして知られているcv
)システムのすべてのプロセス状態を表示します。