是否有一个简单的命令来显示目录（文件夹）中所有文件的总聚合大小（磁盘使用情况）？
我试过这些，他们没有做我想做的:
-
ls -l，只显示目录中单个文件的大小，也不显示 -
df -h，它只显示我的磁盘上的可用和已用空间。
命令 du "总结每个文件的磁盘使用情况，递归地为目录"，例如,
du -hs /path/to/directory-
-h是获取数字"人类可读"，例如get140M而不是143260(以Kb为单位的大小) -
-s是为了摘要（否则你不仅会得到文件夹的大小，而且会得到所有的东西 在 文件夹分开）
正如你所使用的 -h 您可以使用以下方法对人类可读值进行排序
du -h | sort -h该 -h 国旗上 sort 将考虑"人类可读"的尺寸值。
如果要避免递归地列出所有文件和目录，您可以提供 --max-depth 用于限制显示多少项的参数。 最常见的, --max-depth=1
du -h --max-depth=1 /path/to/directory最近我发现了一个很棒的，基于ncurses的交互式工具，它可以快速为您提供有关目录大小的概述。 寻找这种工具已经很多年了。
- 快速钻取文件层次结构
- 您可以从工具内删除例如巨大的临时文件
- 极快
把它想象成 猴面包树 对于命令行:
apt-get install ncdu这将递归地查找大小，并将其放在每个文件夹名称旁边，以及底部的总大小，所有这些都是人类格式
du -hsc *以下是我用于打印总计，文件夹和文件大小的内容:
$ du -sch /home/vivek/* | sort -rh详情
------------------------------------------------------------ -c, --total produce a grand total -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) -s, --summarize display only a total for each argument ------------------------------------------------------------- -h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G) -r, --reverse reverse the result of comparisons输出
70M total 69M /home/vivek/Downloads/gatling-charts-highcharts-bundle-2.2.2/lib992K /home/vivek/Downloads/gatling-charts-highcharts-bundle-2.2.2/results292K /home/vivek/Downloads/gatling-charts-highcharts-bundle-2.2.2/target 52K /home/vivek/Downloads/gatling-charts-highcharts-bundle-2.2.2/user-filestree 是这个工作的另一个有用的命令:
只需通过安装 sudo apt-get install tree 并键入以下内容:
tree --du -h /path/to/directory......33.7M used in 0 directories, 25 files从 人树:
-h Print the size of each file but in a more human readable way, e.g. appending a size letter for kilo‐ bytes (K), megabytes (M), gigabytes (G), terabytes (T), petabytes (P) and exabytes (E).--du For each directory report its size as the accumulation of sizes of all its files and sub-directories (and their files, and so on). The total amount of used space is also given in the final report (like the 'du -c' command.)答案很明显 du 是查找目录总大小的工具。 但是，有几个因素需要考虑:
偶尔,
du输出可能会产生误导，因为它报告了文件系统分配的空间，这可能与单个文件的大小之和不同。 通常，文件系统将为文件分配4096字节，即使您只在其中存储一个字符！由于2的功率和10单位的功率而产生的输出差异。 该
-h切换到du将字节数除以2^10 (1024), 2^20 (1048576) 等给出人类可读的输出。 许多人可能更习惯于看到10的幂（例如1K=1000，1M=1000000），并对结果感到惊讶。
要查找目录中所有文件的大小总和（以字节为单位），请执行以下操作:
find <dir> -ls | awk '{sum += $7} END {print sum}'例子：:
$ du -s -B 1255729664$ find . -ls | awk '{sum += $7} END {print sum}'249008169您可以使用工具灰尘:
PS C:\git> dust 0B ┌── templates │ █ │ 0% 0B ┌─┴ git-core │ █ │ 0% 0B ┌─┴ share │ █ │ 0% 76B ├── readme.md │ █ │ 0% 156K │ ┌── less.exe │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█ │ 2% 2.7M │ ├── git-remote-https.exe│▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█████████████████ │ 42% 3.6M │ ├── git.exe │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒██████████████████████ │ 56% 6.5M │ ┌─┴ git-core │███████████████████████████████████████ │ 100% 6.5M ├─┴ libexec │███████████████████████████████████████ │ 100% 6.5M ┌─┴ . │███████████████████████████████████████ │ 100%我的例子来自Windows，但也支持Linux和Apple:
我习惯于 ll 别名为 ls -alF. 它只是缺少一个文件计数和大小的文件在底部. 我玩过 du 和 tree 但无法得到我需要的总数。 所以我创造了 lll 为我这么做。
在你的 ~/.bashrc 放置以下内容:
lll () { ls -alF "$@" arr=($(ls -alF "$@" | awk '{TOTAL+=$5} END {print NR, TOTAL}')) printf " \33[1;31m ${arr[0]}\33[m line(s). " printf "Total size: \33[1;31m ${arr[1]}\33[m\n"# printf "Total size: \33[1;31m $(BytesToHuman <<< ${arr[1]})\33[m\n"}保存文件并使用资源 . ~/.bashrc （或者你可以重新启动你的终端）。
样本输出
这件好事 ll 输出是它的颜色。 这是保持与 lll 但使用时丢失 find 或 du:
TL;DR
您可以添加到的奖励功能 ~/.bashrc 被称为 BytesToHuman(). 这完成了大多数控制台用户期望将大数字转换为MiB，GiB等的功能:
function BytesToHuman() { # https://unix.stackexchange.com/questions/44040/a-standard-tool-to-convert-a-byte-count-into-human-kib-mib-etc-like-du-ls1/259254#259254 read StdIn b=${StdIn:-0}; d=''; s=0; S=(Bytes {K,M,G,T,E,P,Y,Z}iB) while ((b > 1024)); do d="$(printf ".%02d" $((b % 1024 * 100 / 1024)))" b=$((b / 1024)) let s++ done echo "$b$d ${S[$s]}"} # BytesToHuman ()接下来在两行之间翻转注释 lll () 功能看起来像这样:
# printf "Total size: \33[1;31m ${arr[1]}\33[m\n" printf "Total size: \33[1;31m $(BytesToHuman <<< ${arr[1]})\33[m\n"现在你的输出看起来像这样:
一如既往，不要忘记重新来源 . ~/.bashrc 每当进行更改。 （或者重新启动终端当然）
PS-两个星期的自我隔离终于给了我时间来实现这个五年的目标。
友好的提醒，它可能在像BTRFS这样的CoW文件系统上几乎没有任何意义。