回答:
tl; dr：tar -cv dir | wc -c - | cut -d' ' -f 1 | awk '{print $1/1000"K"}'
du実際にはファイル自体のサイズはカウントされません。カーネルにファイルシステムのクエリを要求するだけで、ファイルシステムはすでにファイルサイズを追跡しています。これがとても速い理由です。そのため、ファイルでduはなくストリームをカウントしているという事実は機能しません。私の推測では、これ1.0Kは/dev/std*カーネルのハードコードされたサイズです。
解決策はwc -c、カーネルを照会する代わりにバイト自体をカウントするを使用することです。
$ tar -cv dir | wc -c
次のような出力が必要な場合du -h：
$ tar -cv dir | wc -c | awk '{print $1/1000"K"}'
awk人間が読める結果に番号を回します。
GNU tarを使用すると、次のことができます。
tar --totals -c . >/dev/null
...出力は次のようになります...
Total bytes written: 5990400 (5.8MiB, 5.5GiB/s)
... stderr上。同様に、任意のtar （またはストリーム）を使用ddして、バイトカウントに関するレポートを配信できます。これはに優先する場合とそうでない場合がありますwcが、ddデフォルトのブロックサイズは512バイトです。これは、のブロックサイズと同じですtar。システムのPIPE_BUFが十分に大きい場合、ddのブロックサイズを拡張して、tarのレコードサイズに一致させることもできます。これは20ブロック、つまり10240バイトです。このような：
tar -c . | dd bs=bx20 >/dev/null
585+0 records in
585+0 records out
5990400 bytes (6.0 MB) copied, 0.0085661 s, 699 MB/s
これは、よりも優れたソリューションを提供する場合と提供しない場合がありますwc。
ただしdd、tarユースケースとユースケースの両方で、実際にストリームを破棄する必要はありません。私はにリダイレクト/dev/null上記の-しかし、私は簡単にいくつかのファイルにリダイレクトし、まだそれが書かれた時点で、そのサイズに関する報告書を受け取った可能性があります。
dd（と比較wc）。
dd出力がコンプレッサーに渡されることを想像してみてください-たとえば、アーカイブの生のサイズと圧縮されたサイズの両方を知っていることが望ましいと思う理由が何であれ。また、レコード数に関する即時レポートを取得することも役立ちtarます。これは単なるアーカイブではなく、ストリーム形式です。ファイルのグループに保存して、他のファイルに保存する以外の方法で使用できます。多くの場合、変更前にストリームをブロックするのに役立ちます。それらの各レコード境界には、NULのブロック全体があります。
私はお勧めします：
tar cf - dir | wc -c
単純なc（先頭-は不要）を使用してtarアーカイブを作成しf、出力ファイルを指定して、stdoutで-あることを示します。（なお、あなただけの大きさをしたいとの下に多くのファイルがある場合、dirはあなたかもしれないというオミットのパフォーマンス上の理由のために。）tarv
tar過去にsを使用してtarファイル（したがってfと-）を指定する必要があったことを思い出したようです。-調べたところです。なしと想定デフォルトとして。f -tar/etc/mt0
/etc/mt0「磁気テープ」という実際の意味を思い出す人はほとんどいません。;-) Solarisのtar動作に興味があります（Solarisは、まだ古いものがあることが知られている現代のOSの1つであるためです/bin）。
-f旗の存在tarですか？
あなたの質問の文言はtar ... | wc -c上記の答えに役立ちます。私はもともと、tarファイルの作成中にサイズを報告する必要があるという暗黙の前提で質問を読みました（おそらく、tarの出力がネットワークリンクを介してパイプ処理されていたのでしょうか？）。
その場合は、pvパイプビューアをお勧めします。私はそれへの言及を見ましたが、まだそれを試す機会がありませんでした。
参考文献
wcの余分な部分を省略した場合-、後続のcutコマンドも不要になることに注意してください。