cross-posted from: https://discuss.tchncs.de/post/13814482
I just noticed that
eza
can now display total disk space used by directories!I think this is pretty cool. I wanted it for a long time.
There are other ways to get the information of course. But having it integrated with all the other options for listing directories is fab.
eza
has features like--git
-awareness,--tree
display, clickable--hyperlink
, filetype--icons
and other display, permissions, dates, ownerships, and other stuff. being able to mash everything together in any arbitrary way which is useful is handy. And of course you can--sort=size
docs:
--total-size show the size of a directory as the size of all files and directories inside (unix only)
It also (optionally) color codes the information. Values measures in kb, mb, and gb are clear. Here is a screenshot to show that:
eza --long -h --total-size --sort=oldest --no-permissions --no-user
Of course it take a little while to load large directories so you will not want to use by default.
Looks like it was first implemented Oct 2023 with some fixes since then. (Changelog). PR #533 - feat: added recursive directory parser with `–total-size` flag by Xemptuous
Off topic, but maybe someone will appreciate this. I wrote a function to get the size of contents of a dir a while back. It has a couple of dependencies (
gc
,gwc
at a glance), but should be fairly portable. The results are sorted from greatest to least as shown in the screenshot.function szup() { description=' #: Title: szup #: Synopsis: sort all items within a directory according to size #: Date: 2016-05-30 #: Version: 0.0.5 #: Options: -h | --help: print short usage info #: : -v | --version: print version number ' funcname=$(echo "$description" | grep '^#: Title: ' | sed 's/#: Title: //g') version=$(echo "$description" | grep '^#: Version: ' | sed 's/#: Version: //g') updated="$(echo "$description" | grep '^#: Date: ' | sed 's/#: Date: //g')" function usage() { printf "\n%s\n" "$funcname : $version : $updated" printf "%s\n" "" } function sortdir() { Chars="$(printf " %s" "inspecting " "$(pwd)" | wc -c)" divider===================== divider=$divider$divider$divider$divider format=" %-${Chars}.${Chars}s %35s\n" totalwidth="$(ls -1 | /usr/local/bin/gwc -L)" totalwidth=$(echo $totalwidth | grep -o [0-9]\\+) Chars=$(echo $Chars | grep -o [0-9]\\+) if [ "$totalwidth" -lt "$Chars" ]; then longestvar="$Chars" else longestvar="$totalwidth" fi shortervar=$(/Users/danyoung/bin/qc "$longestvar"*.8) shortervar=$(printf "%1.0f\n" "$shortervar") echo "$shortervar" printf "\n %s\n" "inspecting $(pwd)" printf " %$shortervar.${longestvar}s\n" "$divider" theOutput="$(du -hs "${theDir}"/* | gsort -hr)" Condensed="$(echo -n "$theOutput" | awk '{ print $1","$2 }')" unset arr declare -a arr arr=($(echo "$Condensed")) Count="$(echo "$(printf "%s\n" "${arr[@]}")" | wc -l)" Count=$((Count-1)) for i in $(seq 1 $Count); do read var1 var2 <<< "$(printf "%s\n" "${arr[$i]}" | sed 's/,/ /g')" printf " %5s %-16s\n" "$var1" "${var2//\/*\//./}" done echo } case "$1" in -h|--help) usage return 0 ;; *) : ;; esac if [ -z "$1" ]; then oldDir="$(pwd)" cd "${1}" local theDir="$(pwd)" sortdir cd "$oldDir" return 0 else : oldDir="$(pwd)" cd "${1}" local theDir="$(pwd)" sortdir cd "$oldDir" return 0 fi }``` Screenshot isn't working. I'll reply to this with it.
Is this effectively the same as:
du -hs * | sort -h
?Hahaha. I may have spent a lot of time creating a script to implement functionality that was already there.
du -hs * | sort -h -r
, I guess.
Thanks! I always appreciate another tool for this. I tried to run it but have dep issues.
What is
gwc
? I can’t find a package by that name nor is it included that I can see.Websearch finds GeoWebCache, Gnome Wave Cleaner, GtkWaveCleaner, several IT companies… nothing that looks relevant.
edit: also stumped looking for
gsort
. it seems to be associated with something called STATA which is statistical analysis software. Is that something you are involved with maybe running some special stuff on your system?PS you missed a newline at the end before closing the code block which is why the image was showing up as markdown instead of displaying properly.
Change:
}```
to:
} ```
Aha with the new line! Thank you!
I believe
gwc
andgsort
are part ofcoreutils
based on this:$ gwc --help Usage: gwc [OPTION]... [FILE]... or: gwc [OPTION]... --files0-from=F Print newline, word, and byte counts for each FILE, and a total line if more than one FILE is specified. A word is a nonempty sequence of non white space delimited by white space characters or by start or end of input. With no FILE, or when FILE is -, read standard input. The options below may be used to select which counts are printed, always in the following order: newline, word, character, byte, maximum line length. -c, --bytes print the byte counts -m, --chars print the character counts -l, --lines print the newline counts --files0-from=F read input from the files specified by NUL-terminated names in file F; If F is - then read names from standard input -L, --max-line-length print the maximum display width -w, --words print the word counts --total=WHEN when to print a line with total counts; WHEN can be: auto, always, only, never --help display this help and exit --version output version information and exit GNU coreutils online help: <https://www.gnu.org/software/coreutils/> Full documentation <https://www.gnu.org/software/coreutils/wc> or available locally via: info '(coreutils) wc invocation'
So, exa became eza. Thanks. https://github.com/ogham/exa
exa is unmaintained, use the fork eza instead. (This repository isn’t archived because the only person with the rights to do so is unreachable).
Oh, I had no idea, time to change some aliases
Some of the distros actually just included an alias from
exa
toeza
when the project forked. I didn’t even realize I was usingeza
for a long time!
I just tested this and the reported sizes with
eza -l --total-size
are wrong for me. I compare it todu --human-readable --apparent-size --all --max-depth 1
and with opening properties in my Dolphin filemanager. Some are way off. In exampledu
and Dolphin report for a certain projects folder of mine “149M”, whileeza
reports “184M”.this looks like one is using the SI 1000-based units, instead of the binary 1024-based. im pretty sure
du
has a--si
option.the
B
(for bytes) is omitted, so it each is ambiguous to whether itsMiB
(mebibytes – binary) orMB
(megabytes – SI).i may be wrong on the technicals but u get the jist.
The difference is too large for that. 184 MB is 176 MiB not 149.
No, the difference is way too high to explain it like this, there is no way that 1024 vs 1000 base could explain an increase of approx. “35M” for a “149M” directory. Other folders are much closer like “20K” and “20K” or =or “44M” vs “45M”. Also as said Dolphin filemanager reports the same output as
du
. I even testeddu
with--si
option, which power of 1000 instead 1024 (I’m pretty sureeza
does it correctly with 1024, so this is not necessary option to compare anyway).No, @lseif@sopuli.xyz is correct.
I just did a test using
dd
- I created 100 files of exactly 1 MiB each (1048576 bytes).du
reported the size as “100M” as expected, whereaseza
reported it as “105M” - which is what you’d get if you divided 104857600 by 1000000 (= 104.8576 or 105M if you round it off).He is wrong, as I explained it multiple times that this is not the issue here. Install
eza
and compare todu
and possibly some other application that reports the directory size. The difference in filesize cannot be explained by 1000 vs 1024 base. Do the math if you don’t believe me.eza
is reporting false directory size for me, unless there is an explanation.[Desktop]$ du --human-readable --apparent-size --all --max-depth 1 ./trampoline 518 ./trampoline/src 148M ./trampoline/target 1,1M ./trampoline/doc 8 ./trampoline/.gitignore 26K ./trampoline/.git 330 ./trampoline/Cargo.toml 2,1K ./trampoline/Cargo.lock 149M ./trampoline [Desktop]$ du --human-readable --apparent-size --all --max-depth 1 --si ./trampoline 518 ./trampoline/src 155M ./trampoline/target 1,2M ./trampoline/doc 8 ./trampoline/.gitignore 27k ./trampoline/.git 330 ./trampoline/Cargo.toml 2,2k ./trampoline/Cargo.lock 157M ./trampoline [Desktop]$ eza -l --total-size --no-permissions --no-user ./trampoline 2,1k 25 Feb 21:36 Cargo.lock 330 4 Mär 09:21 Cargo.toml 1,1M 5 Apr 12:34 doc 518 5 Apr 12:49 src 183M 4 Apr 20:26 target
And for reference Dolphin the filemanager of KDE Plasma reports
149,1 MiB (156.366.443)
, which aligns withdu
without using--si
option. Even the one folder “target” is at183M
witheza
(which is the biggest folder in that directory anyway).I was talking about the 1000 vs 1024 issue, do the dd test yourself and it’s easy to verify that he was right.
As for the specific descrepancy that you’re seeing, lots of things can throw off a file size calculation - symlinks, sparse files, reflinks, compression etc. Since you’re the only one with access to your files, you’ll need to investigate and come to a conclusion yourself (and file a bug report if necessary).
hmm I didn’t think to actually test the results. But now that i do, I get same sort of descrepency.
How about this?
eza --long -h --total-size --sort=size --no-permissions --no-user --no-time -a --blocksize --binary
that works in a couple test directories with the column
Blocksize
.Also it might (??) be ignoring according to your
gitignore
if that is relevant? Or behaving differently wrt symlinks?Seems like the default behavior should be whatever is most expected, standard and obvious. Or else give user a hint.
I find this in the repo, is t relevant?: bug: Inconsistent Size Display in `exa` Command for Large Files (1024 vs. 1000 Conversion) · Issue #519.
don’t forget
eza --version
. I find it is not updated quickly in every distro. See changelog; it looks like there might have been a relevant update as recently as[2024-03-06
. Actual my system is only updated to ] -0.17.3
now that I check this too.With
--binary
option I get size of174Mi
ineza
. Experimenting with some other options didn’t help. If something is ignored (maybe gitignore), then it would be thatdu
AND Dolphin filemanager would ignore those files, andeza
would not. Which its hard to believe for me. I also deleted the .gitignore and .git files/folder to see if it makes any difference and no, it did not.The only thing I can think of is maybe something going on with link files, but no idea how or what to test for here.
well I guess a way to test would be to create a new directory and copy or create some files into it rather than using a working directory where there are unknown complexities. IIRC
dd
can create files according to parameters.Start with a single file in a normal location and see how to get it to output the correct info and complicate things until you can find out where it breaks.
That’s what I would do, but maybe a dev would have a more sophisticated method. Might be worth while to read the PR where the feature was introduced.
Also kind of a shot in the dark but do you have an ext4 filesystem? I have been dabbling with btrfs lately and it leads to some strange behaviors. Like some problems with rsync. Ideally this tool would be working properly for all use cases but it’s new so perhaps the testing would be helpful. I also noticed that this feature is unix only. I didn’t read about why.
it would be that
du
AND Dolphin filemanager would ignore those files, andeza
would not. Which its hard to believe for me.Although only 1 of various potential causes, I don’t think it is implausible on its face.
du
probably doesn’t know aboutgit
at all right? If nautilus has a VCS extension installed I doubt it would specifically ignore for the purposes of calculating file size.I have found a lot of these rust alternatives ignore
.git
and other files a little too aggressively for my taste. Bothfd
(find
), andag
(grep
) require 1-2 arguments to include dotfiles,git
-ignored and other files. There are other defaults that I suppose make lots of sense in certain contexts. Often I can’t find something I know is there and eventually it turns out it’s being ignored somehow.About the gitignore stuff of Rust tools: Its the opposite for my results, in that eza has bigger size. And the fact that the independent program Dolphin filemanager aligns with the output of the standard du tool (for which I don’t have a config file I think) speaks for being the more correct output.
Ok so I found it: Hardlinks
$ \ls -l total 9404 -rwxr-xr-x 2 tuncay tuncay 4810688 5. Apr 10:47 build-script-main -rwxr-xr-x 2 tuncay tuncay 4810688 5. Apr 10:47 build_script_main-947fc87152b779c9 -rw-r--r-- 1 tuncay tuncay 2298 5. Apr 10:47 build_script_main-947fc87152b779c9.d $ md5sum * 6ce0dea7ef5570667460c6ecb47fb598 build-script-main 6ce0dea7ef5570667460c6ecb47fb598 build_script_main-947fc87152b779c9 68e78f30049466b4ca8fe1f4431dbe64 build_script_main-947fc87152b779c9.d
I went down into the directories and compared some outputs until I could circle it down (is it called like that?). Look at the number
2
, which means those files are hardlink. Their md5 checksum are identical. So its what I was thinking all along, some kind of linking weirdness (which in itself is not weird at all). Soeza
is not aware of hardlinks and count them as individual files, which is simply wrong, from perspective of how much space those files occupy. The file exists once on the disk and requires only one time space.EDIT: BTW sorry that my replies turned your news post into a troubleshooting post. :-(
Why does ls need a replacement?
What does this do that ls cannot?
Edit: cheers for the downvote for valid questions!! Guess the reddit mindset never leaves some.
aside from the subject of the post: the ones I miss when it’s not available are git status/ignoring, icons, tree, excellent color coding.
Here I cloned the
eza
repo and made some random changes.eza --long -h --no-user --no-time --almost-all --git --sort=date --reverse --icons
Made some more changes and then combine
git
andtree
, something I find is super helpful for overview:eza --long -h --no-user --no-time --git --sort=date --reverse --icons --tree --level=2 --git-ignore --no-permissions --no-filesize
(weird icons are my fault for not setting up fonts properly in the terminal.)
Colors all over the place are an innovation that has enabled me to use the terminal really at all. I truly struggle when I need to use b&w or less colorful environments. I will almost always install
eza
on any device even something that needs to be lean. It’s not just pretty and splashy but it helps me correctly comprehend the information.I’d never want to get rid of
ls
and I don’t personally alias it to toeza
because I always want to have unimpeded access to the standard tooling. But I appreciate having a few options to do the same task in slightly different ways. And it’s so nice to have all the options together in one application rather than needing a bunch of scripts and aliases and configurations. I don’t think it does anything that’s otherwise impossible but to get on with life it is helpful.Not sure I could get with the huge string of arguments, That needs to be shortened to follow the ls style of stacking letters behind minimal “-”
Does look good but I prefer function to form.
Interesting though
oh of course there are abbreviated forms. I just used the long versions so that people who aren’t framiliar can follow what I am doing without having to spend 10 mins cross referencing the man page.
Likewise in the examples I used options that created a fairly very simple screenshot to clearly illustrate an answer to the question of what
eza
does thatls
doesn’t.I tend to use
eza
via a couple of aliases with sets of common preferences. Like in a git dir I want to sort by date. usually don’t need to see the user column, the size or permissions (except when I do). I do want to see the dotfiles. So I have an appropriate line aseg
(eza git). A great companion togs
.
It’s subjective, but it looks better
Function is what I want.
good design is a function on its own
better defaults, icons, color coding, and other optional views improve on the functions of the default ls
You do you choom