そのディレクトリからそれらを削除する最も速い方法は、それらをそこから移動することです。その後、バックグラウンドでそれらを削除するだけです:
mkdir ../.tmp_to_remove
mv -- * ../.tmp_to_remove
rm -rf ../.tmp_to_remove &
これは、現在のディレクトリがマウントされたパーティションのトップレベルではないことを前提としています (つまり、その 08 は同じファイルシステムにあります)。
18 26 の後 33 で始まるファイル/ディレクトリ名がある場合は、(Stéphane によって編集されたとおり) が必要です。 .
上記は、サブディレクトリを再帰的に処理する必要がないため、現在のディレクトリからファイルを一瞬で削除します。ファイルシステムからのツリーの実際の削除には時間がかかりますが、邪魔にならないので、実際の効率はそれほど重要ではありません。
48 驚くほど速くて簡単です。最初に空のディレクトリを作成する必要があります。
mkdir emptydir rsync -a --delete emptydir/ yourdirectory/
53 ファイルを削除するディレクトリです。
65 の 1 つの問題 、またはより正確な同等の 78 シェルは最初に、現在のディレクトリ内のすべての (非表示でない) ファイルを一覧表示し、それらを並べ替えて 84 に渡します。 、現在のディレクトリ内のファイルのリストが大きい場合、不要な余分なオーバーヘッドが追加され、ファイルのリストが大きすぎる場合は失敗することさえあります.
通常は 98 とします 代わりに（隠しファイルも削除できるという利点もあります）。しかし、ほとんどの 105 すべての POSIX 準拠のものを含む実装は、それを拒否します。その理由は、一部のシェル (すべての POSIX シェルを含む) には、116 の展開という誤った機能があるためです。 glob には 121 が含まれます と 138 .つまり、148 現在のディレクトリと親ディレクトリを削除するため、157 これらのシェルの不具合を回避するために修正されました.
160 のような一部のシェル (およびその他の Forsyth シェルの派生物)、170 または 184 その欠点はありません。 198 203 があります 214 で有効にできるビルトイン 223 以来 の 236 246 は含まれません 259 でもありません 263 で問題なく動作します .だから 274 、できること:
autoload zsh/files
rm -rf .
Linux では、次のことができます:
rm -rf /proc/self/cwd/
現在のディレクトリを空にするか、
rm -rf /dev/fd/3/ 3< some/dir
任意のディレクトリを空にします。
(末尾の 285 に注意してください )
GNU システムでは、次のことができます:
find . -delete
ここで、現在のディレクトリにいくつかのエントリしかなく、ファイルの大部分がサブディレクトリにある場合、大きな違いはなく、297 おそらくあなたが得ることができる最も速いでしょう。 306 に期待されます （またはすべてのファイルを削除するもの）は、すべてのディレクトリのコンテンツを読み取って 312 を呼び出すことを意味するため、コストがかかります すべてのエントリで。 325 削除されたファイルの i ノード、ファイルを含むディレクトリ、ファイル システム マップ、またはその他の空き領域を変更する必要があるため、それ自体が非常に高くつく可能性があります。
338 と 342 (少なくとも GNU 実装では) すでに各ディレクトリの inode 番号でファイルのリストを並べ替えています。これは、ext4 ファイル システムでのパフォーマンスの点で大きな違いを生む可能性があります。相互に) inode は順番に変更されます。
356 ファイルを名前でソートすると、名前順が inum 順と一致しない限り (ファイル名のソートされたリストからファイルが作成された場合など)、パフォーマンスが大幅に低下する可能性があります。
365 の理由の 1 つ 373 または 389
もう少し最適化するには:
ディレクトリ ツリーの最大深度がわかっている場合は、それを 391 に渡すことができます。 :
find . -maxdepth 3 -delete
401 を節約できます ディレクトリの内容を深さ 3 で読み取ろうとする必要があります。