在Unix中,是否可以使用ls
列出子目录及其所有内容的总大小,而不是通常的4K
(我认为)只是目录文件本身的大小?
total 12K
drwxrwxr-x 6 *** *** 4.0K 2009-06-19 10:10 branches
drwxrwxr-x 13 *** *** 4.0K 2009-06-19 10:52 tags
drwxrwxr-x 16 *** *** 4.0K 2009-06-19 10:02 trunk
在查看了man手册后,我毫无头绪。
我曾经在RHEL 6.0上的Gnome桌面使用Nautilus删除我的主目录下的文件,而非使用bash中的rm
命令。导致结果是:
du -sh
当我使用时,总磁盘使用量与每个子目录的磁盘使用量之和不匹配。
du -sh *
我花了一段时间才意识到Nautilus将删除的文件发送到其垃圾桶文件夹中,该文件夹未列在du -sh *
命令中。因此,只是想分享一下,以防有人遇到同样的问题。
嗯,最好的方法是使用这个命令:
du -h -x / | sort -hr >> /home/log_size.txt
sudo
du -hsx 2>/dev/null *
0 bin
4.0K boot
0 dev
9.0M etc
6.5M home
824K init
0 lib
0 lib32
0 lib64
0 libx32
16K lost+found
4.0K media
4.0K mnt
4.0K opt
0 proc
61M root
36K run
0 sbin
4.0K srv
0 sys
4.0K tmp
2.2G usr
4.9G var
find . -maxdepth 1 -exec du --apparent-size --max-depth=0 --null '{}' ';' |\
sort -k1 -nr --zero-terminated |\
cut -f2 --zero-terminated |\
xargs --null -n 1 du -h --apparent-size --max-depth=0
特点:
--apparent-size
与du
以获得类似于ls
的行为。我遇到了一个类似于Martin Wilde所描述的问题,在我的情况下是在使用rsync镜像后比较两个不同服务器上的相同目录。
我没有使用脚本,而是将-b
标志添加到du
中,该标志计算字节大小,并且据我所知消除了两个服务器上的差异。您仍然可以使用-s -h
来获取易于理解的输出。
这里需要注意的是,du
命令可以给出磁盘使用情况。不同的机器可能使用不同的块大小,因此在一台机器上,一个块的大小可能为4096字节,而另一台机器可能包含2048字节的块大小。如果我在使用4096字节块的机器上放置了10个1字节文件,并在使用2048字节块的机器上放置了10个1字节文件,则 du -h
分别报告约为40k和20k。
如果您想知道目录中所有文件的大小,对于每个目录,您可以执行以下操作:
for x in ./*;
do
if [[ -f "$x" ]]; then
ls -al "$x"
fi
done | awk '{print $6}' | awk '{s+=$1}END{print s}'
这将为您提供目录中所有文件的总大小。
将其放置在类似于.bashrc的init脚本中...根据需要调整def。
duh() {
# shows disk utilization for a path and depth level
path="${1:-$PWD}"
level="${2:-0}"
du "$path" -h --max-depth="$level"
}
从ls中仅检索以字节为单位的大小。
ls -ltr | head -n1 | cut -d' ' -f2
输入命令"ls -ltrh /path_to_directory"
alias ducks='du -cksh * | sort -hr | head -n 15'
。该命令将显示当前目录下占用磁盘空间最多的前15个文件或文件夹,并按照从高到低的顺序排列。 - Sebialias ducks='du -cksh * | sort -hr | head -n 15'
中的-h
选项和du
的-c
选项大多是非便携式 GNU 扩展,而不是 POSIX 标准du
和sort
实用程序。如果没有-h
选项,则必须使用-n
选项调用sort
进行数字排序,简化为:du -sk * | sort -n
。 - Andrew Henlesort
中省略-r
,并且不通过head
(或tail
)传递结果,将整个结果发送到终端,最大的结果最后显示。这在交互式会话中非常有用。请注意,*
将跳过以.
开头的文件和目录,例如.m2
。 - Andrew Henle