How to Show Recursive Size of Directories?

[amarz45]

When using '-l', exa only shows the size of files. It doesn't show the size of directories. I want it to show the size of the directories including the size of everything inside the directory (recursive) similar to the '--total-size' option in lsd which is a different alternative to ls.

[StewAlexander-com]

@Amarakon55 the case could be made then that exa would not be a drop-in replacement for ls if it does that work

Btw - this isn't the way a lot of operating systems behave out-of-the-box

There's a speed tradeoff as that would take the program time to add all the file sizes up in the directory trees under the current directory (as Linux / Debian systems don't do this by default - a gripe really for Linus Torvalds or the Canonical team)

Maybe someone can develop it as a flag option, as in "--show-directory-sizes"?

[amarz45]

Yes, it would be better if it wasn't the default behavior, but a flag option instead for those who want it.

[CouldBeThis]

the other day I tested a whole slew of ls replacements and found one which has this feature, lsd. it is also written in rust I have no idea if helpful. I will definitely be keeping it around for this feature alone.

[faelin]

There's a speed tradeoff as that would take the program time to add all the file sizes up in the directory trees under the current directory (as Linux / Debian systems don't do this by default - a gripe really for Linus Torvalds or the Canonical team)

Given that Exa already knows which nodes are directories and already knows the size content of files in those directories, I have trouble with the notion that simply summing all of the size values nested below a particular directory would be more than trivial.

[ariasuni]

Given that Exa already knows which nodes are directories and already knows the size content of files in those directories, I have trouble with the notion that simply summing all of the size values nested below a particular directory would be more than trivial.

It’s easy to think something is trivial when you don’t know the code.

Exa doesn’t know the size of the files in the directories below, except when using recursive modes (like --long -tree), but sometimes you don’t go to the full depth, and you need to look up files you usually filter out (like hidden files, or files ignored by Git if you use --git-ignore) without displaying them; that’s not even considering the fact that it introduces a backtracking, which is to say that as of right now, exa can do the render for each file independently, but with this option, to know how to render folder line it needs to wait for everything inside it to have been checked, which would need some refactoring; and obviously it would need some serious testing with a lot of configuration.

So sure, additions are simple. But the change in question needs a lot of steps and require attention to a lot details that makes it complex.

[faelin]

@ariasuni my apologies for the dismissive comment. You raise some excellent points, which I had not adequately considered.

Perhaps some day an additional feature can be implemented, that is specifically built to analyze disk usage, starting at the PWD.

[ariasuni]

Thanks. Well new features can certainly be implemented and I plan to continue working on exa but I just don’t have enough time™ to make progress at a pace that satisfies people (and I understand that, but it’s frustrating for me as well and I can’t do much more than what I’m actually doing).

I’m not sure about this feature, especially the ratio asked for vs needed work, but I guess it could be done. Right now my main focus is merging some old PRs, improving the CI to not break things when merging big/ambitious changes, and triaging/answering the issues (actually most of my work is this latest one).

[Jieiku]

I currently use some aliases in my .zshrc file:

# EXA Tree Aliases optionally accepts directory eg: "t2" to show two levels or specify location "t2 ~/Downloads"
# For all levels just use "t" or "t ~/Downloads"
t() {
exa -T -a --icons -g -s .name -l "$@"
}
t1() {
exa -T -a --icons -g -s .name -l -L=1 "$@"
}
t2() {
exa -T -a --icons -g -s .name -l -L=2 "$@"
}
t3() {
exa -T -a --icons -g -s .name -l -L=3 "$@"
}
t4() {
exa -T -a --icons -g -s .name -l -L=4 "$@"
}
t5() {
exa -T -a --icons -g -s .name -l -L=5 "$@"
}
t6() {
exa -T -a --icons -g -s .name -l -L=6 "$@"
}
t7() {
exa -T -a --icons -g -s .name -l -L=7 "$@"
}
t8() {
exa -T -a --icons -g -s .name -l -L=8 "$@"
}
t9() {
exa -T -a --icons -g -s .name -l -L=9 "$@"
}

produces output like this:

I would absolutely love an extra option flag (non default behavior) that allows it to display the size of the contents of the directories, even if it meant it took a little longer to do the work and display.

Based on the other comments here I installed lsd, I was able to accomplish something similar with this command:

lsd --total-size --sizesort -l

which produced the output:

[roulette6]

My solution is not exa/eza either, but tree worked well for me.

\tree -h --du --dirsfirst -L 2
[137K]  .
├── [ 12K]  logging-services
│   ├── [4.0K]  alloy
│   └── [4.0K]  loki
├── [ 37K]  monitoring
│   ├── [4.0K]  alloy
│   ├── [4.0K]  blackbox-exporter
│   ├── [4.0K]  loki
│   ├── [4.0K]  mimir
│   ├── [4.0K]  prometheus
│   ├── [4.0K]  promtail
│   ├── [4.0K]  snmp_exporter
│   ├── [4.0K]  uptimekuma
│   └── [ 797]  snmp-notes.txt
├── [ 12K]  proxy-services
│   ├── [4.0K]  authentik
│   └── [4.0K]  traefik
├── [ 36K]  services
│   ├── [4.0K]  cloudflared
│   ├── [4.0K]  filebrowser
│   ├── [4.0K]  homepage
│   ├── [4.0K]  homepage-cf
│   ├── [4.0K]  homer
│   ├── [4.0K]  homer-cf
│   ├── [4.0K]  pihole
│   └── [4.0K]  uptime-kuma
├── [ 36K]  stacks
│   ├── [4.0K]  monitoring
│   ├── [4.0K]  services-authentication
│   ├── [4.0K]  services-dashboards
│   ├── [4.0K]  services-docker
│   ├── [4.0K]  services-file
│   ├── [4.0K]  services-logging
│   ├── [4.0K]  services-network
│   └── [4.0K]  services-proxy
└── [  79]  README.md