You run du. It spits out numbers, paths, nested folders, permission errors, mount points, and possibly the entire history of Western civilization. Then you start adding flags until the command looks like you lost a fight with your keyboard:

du -h --max-depth=1 . | sort -hr

That works. Mostly. But it still does not quite show the information the way I normally want to see it.

I want a simple table.

Show me the folders directly under the current directory. Show me how large each one is. Show me how much space the loose files in the current directory consume. Show me the total. While you are at it, tell me how full the filesystem is so I know whether I am doing routine cleanup or participating in an emergency.

That is what dsize does.

What Is dsize?

dsize is a Bash terminal tool I wrote that displays directory sizes in a human-readable, color-coded table. It also shows usage information for the filesystem where the directory lives.

That is it. That is the pitch.

It is not a full disk-management suite. It does not launch a TUI, index your entire drive, create an SQLite database, require a daemon, or ask you to create an account so it can show you how large your Downloads folder is.

It is one Bash script.

Run:

dsize

And get a readable view of the current directory.

You can also point it somewhere else:

dsize /var/log

Now you can find out which log folder has decided it wants to become the primary occupant of your storage device.

But Why Though?

I got irritated.

That appears to be how a suspicious number of my little tools get started.

I use du regularly, and du is great at what it does. The problem is that I kept running some variation of the same command, piping it into sort, mentally separating the current directory from its subdirectories, and then running df separately to see whether the filesystem itself was getting full.

None of this is particularly difficult. But neither is walking across the room every time you want to change the television channel. We still invented the remote.

I wanted one command that showed the information in the way I naturally look for it:

The . row represents files stored directly in the directory being scanned. It does not include the contents of the subdirectories listed below it.

That distinction matters when you have seventeen ISO files, four database backups, and something named final-final-REAL-backup.tar.gz sitting loose in a folder.

What dsize Does

Under the hood, dsize does a few things to turn ordinary Linux commands into something easier to glance at.

It:

1. Calculates the combined size of files stored directly in the selected directory.
2. Uses a single du pass to collect the recursive size of each immediate subdirectory.
3. Sorts the folders from largest to smallest.
4. Skips duplicate directories that resolve to the same device and inode.
5. Calculates a total for the displayed content.
6. Uses df to retrieve total, used, and available space for the current filesystem.
7. Formats everything into dynamically sized tables.
8. Adds color so larger folders are easier to spot without studying every number like it will be on the test.

The single du pass is worth mentioning. The script does not repeatedly rescan every folder to gather different pieces of information. Storage can be slow enough without me helping it become slower.

Color Coded Sizes

Folder sizes are colored based on their magnitude:

The colors are not trying to tell you that every 10 GB folder is bad. Sometimes a folder is supposed to be large.

A virtual machine image being 40 GB is understandable. A cache folder being 40 GB may need to explain itself.

The filesystem information is also color aware. As usage climbs, the available-space value changes from normal to yellow, orange, and eventually the sort of red normally reserved for warning lights and questionable financial decisions.

If less than half the filesystem is used, dsize leaves it alone. Your disk is doing fine. Relax.

Installation

Clone the repository:

git clone https://github.com/emo333/dsize.git
cd dsize
chmod +x dsize

You can run it directly from the repository:

./dsize

Or scan another directory:

./dsize /path/to/directory

Install It as a Global Command

The most useful setup is to place the script somewhere on your PATH.

For a system wide installation:

sudo cp dsize /usr/local/bin/dsize
sudo chmod +x /usr/local/bin/dsize

After that, you can run it from anywhere:

dsize

Or:

dsize ~/Projects

You can now say, “I use dsize, BTW.”

Whether anyone asked is irrelevant.

Install It for Only Your User

You can also install it under ~/.local/bin without using sudo:

mkdir -p ~/.local/bin
cp dsize ~/.local/bin/dsize
chmod +x ~/.local/bin/dsize

Make sure ~/.local/bin is included in your PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Users of another shell should add it to the appropriate shell configuration file. You zsh peeps know what to do.

Using dsize

Scan the Current Directory

dsize

No arguments means “show me what is happening right here.”

Scan a Specific Directory

dsize /var/lib

Or:

dsize ~/Downloads

The Downloads folder is frequently where files go to live after completing their original purpose. It is basically a digital junk drawer, except nobody occasionally finds twelve dollars in it.

Run the Script Without Installing It

You can execute the file directly:

./dsize

You can also explicitly invoke Bash:

bash ./dsize /path/to/directory

The repository README includes options for using an alias or shell function, but placing it in ~/.local/bin or /usr/local/bin is the cleanest approach for most people.

Requirements

dsize is intended for Linux systems with:

• Bash 4.0 or newer
• GNU du
• GNU stat
• find
• df
• awk
• sed
• sort
• readlink



There is no Python environment to create. No Node packages to install. No Rust compilation step. No Electron application consuming 900 MB of memory so it can display three columns of text.




Just Bash and the GNU command line utilities that are already installed on most Linux distributions.




Because the script uses GNU specific command options, macOS and BSD systems may need GNU coreutils installed or some modifications to the script.




Windows users could probably run it inside WSL, which is where Linux tools go when they have been asked to attend a Windows meeting.




About the . Entry




The . row can look slightly unusual the first time you run dsize.




It represents the combined size of files directly inside the selected directory. Subdirectories are calculated and displayed separately.




For example, suppose a project contains:




project/
├── application.log
├── backup.sql
├── src/
├── tests/
└── build/




The . row contains the sizes of application.log and backup.sql.




The src, tests, and build folders each receive their own row containing their recursively calculated sizes.




This makes it easier to tell whether a directory is large because of its subfolders or because somebody dropped a 37 GB database export directly into the project root and quietly walked away.




Duplicate and Mounted Directories




Filesystems can get weird.




A directory might appear through a bind mount, a symbolic link, or another path that ultimately resolves to the same underlying location. Counting both paths would make the displayed total misleading.




dsize resolves each directory to its real path, reads its device and inode information, and skips entries it has already counted.




This is not an attempt to solve every exotic filesystem arrangement ever invented by humans with too much coffee. It is there to avoid the common cases where the same directory could otherwise be counted more than once.




Filesystem Information




After displaying the directory table, dsize shows the filesystem associated with the selected path:




----------------------
| Mount: /dev/nvme0n1p2 |
----------------------
| 931.5G | Total      |
| 712.8G | Used       |
| 171.3G | Avail      |
----------------------




That information comes from df, and it gives the folder size results some context.




Finding a 12 GB folder means something different when you have 700 GB available than it does when the drive has 400 MB remaining and your system is beginning to make the electronic equivalent of nervous eye contact.




dsize is not a replacement for df. It just puts the relevant information next to the directory sizes because that is usually where I want to see it.




Configuration




There is not much to configure, intentionally.




The table padding is controlled near the top of the script:




readonly PADDING=2




The ANSI color values and size thresholds are also defined there. You can change them if you want different colors or have strong opinions about when a folder should become orange.




I do not currently have a configuration framework, YAML file, plugin system, theme marketplace, or cloud synchronized profile.




It is a "folder size" script. We are going to try to remain calm.




How It Works




The basic flow looks like this:




Selected directory
        |
        +--> Find files directly in the directory
        |        |
        |        +--> Add their byte sizes
        |
        +--> Run du once for immediate subdirectories
        |        |
        |        +--> Resolve real paths
        |        +--> Deduplicate by device and inode
        |        +--> Sort by size
        |
        +--> Read filesystem information with df
        |
        +--> Calculate table dimensions
        |
        +--> Add ANSI colors
        |
        +--> Print the tables




The script writes its prepared output to a temporary file before displaying it and uses a trap to clean that file up when it exits.




There is no background service and nothing remains running after the command finishes. dsize appears, tells you which folder ate the disk, and leaves.




Like a responsible utility.




What dsize Is Not




dsize is not intended to replace tools such as ncdu, dust, dua, or full graphical disk usage analyzers.




Those tools can explore entire filesystems, drill into nested folders, delete files interactively, generate visualizations, and perform more advanced analysis.




They are excellent when you need those features.




dsize is for the moment when you are already in a directory and want a quick answer to:




> Which folders are large, how large are they, and how much space is left on this filesystem?




One command. One table. Back to whatever you were doing before your drive started acting suspicious.




Development




There is not much ceremony involved:



1. Clone the repository.
2. Edit the dsize Bash script.
3. Run it against a few directories.
4. Make sure it does not lie about your storage.
5. Submit a pull request.



There is no build process. There is no dependency restoration. There is no twelve stage CI pipeline deploying a folder size script into a Kubernetes cluster.




It is Bash. We can survive without an architecture review board.




The Pitch




Linux already has the tools needed to calculate directory sizes. dsize does not invent a new way to measure files.




It takes the information I normally gather from du, find, stat, and df, and presents it in the way I actually want to consume it.




Readable table. Human friendly sizes. Largest folders first. Filesystem information included. Colors where they help.




It is not revolutionary. It is not trying to be.




It is just a small tool that does one thing and does it in a way that saves me from rebuilding the same command pipeline every time I wonder where my storage went.




A folder size hammer.




No, that analogy does not work as well as the question hammer from the ask post.




But y’all know what I mean.




Resources




Check it out on GitHub:




emo333/dsize




Shout Outs




YSAP(Dave Eddy) - This dude is the Yoda🧙‍♂️ of Bash