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

    • Vilian@lemmy.ca
      link
      fedilink
      arrow-up
      10
      ·
      8 months ago

      the creator of exa wasn’t rechable for year and the true maintainer that made all the commits in exa decided to fork so he could add others maintainers

      • TxzK
        link
        fedilink
        arrow-up
        4
        ·
        8 months ago

        yeah the title says “formerly exa”, so I thought they just changed the name

  • wewbull@iusearchlinux.fyi
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    19
    ·
    8 months ago

    ls does 90% of this stuff already, so why not just add the options to it?

    looks at readme

    eza: A modern, maintained replacement for ls.

    ls is maintained so what do they mean? “Modern”?

    looks at code tab

    Oh! It’s another person thinking the world needs to be written in Rust.

    • linuxPIPEpower@discuss.tchncs.deOP
      link
      fedilink
      arrow-up
      20
      ·
      8 months ago

      why not just add the options to it?

      If you are asking me, personally, it’s because making any contributions to ls is far beyond my capacities and will remain that way for the forseeable future.

      Personal deficiencies aside, would it even be a good idea to modify ls in this way? It seems to me that stability and predictability is a feature, not a bug. Basically you know how ls will work on every linux system. Adding all these features would turn it into something else and potentially introduce chaos. ls is tested on >millions of systems in every context; a known quantity. A feature set which is limited to the necessities avoids introducing bugs, flaws, security issues etc.

      And once added, a feature probably shouldn’t be removed. In 2024 I love having git status optionally integrated into my ls-type tool. But in 2034 will git still be as ubiquitous? What about 2054? ls is for the ages. eza is for right now.