tree Command on Mac: What the find | sed Alias Gets Wrong

Type tree in a fresh Mac terminal and zsh answers with this:

zsh: command not found: tree

macOS 26.4.1 ships mtree, usdtree and a Perl htmltree, but nothing that draws a directory tree. The most-viewed question on this, Mac OS X equivalent of the Ubuntu tree command on Super User, has 467,577 views. Its accepted answer (713 votes) says to install it. The next most-copied answer is a one-line find | sed alias that turns up in three answers across Super User and Stack Overflow. I installed tree 2.3.2 on this Mac mini and ran it next to the alias and three other fallbacks from that thread, on one 24-entry test folder. The alias works, but its output differs from tree in ways that are easy to misread.

Install tree on a Mac

With Homebrew it is one command:

brew install tree
tree --version   # tree v2.3.2 (c) 1996 - 2026 by Steve Baker, ...

The bottle is 9 files and 195.2 KB. The Homebrew formula page counts 374,460 installs in the past year. MacPorts users get the same program with sudo port install tree. It is not part of GNU coreutils, so brew install coreutils does not include it.

One failure shows up on Apple silicon. A 2023 Super User question reports brew install tree on an M2 failing with Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)!. That message means the Homebrew in use is an Intel install under /usr/local, usually carried over from an older Mac. tree is not the problem. A native install lives in /opt/homebrew, and that is where mine went.

Five ways to print a tree, one folder

The test folder has the usual mess: a .git directory, a .env, node_modules, a folder named my docs, a symlink linked -> src, file names in mixed case, and a file called trailing. that ends in a dot. Here is what each method printed.

Method	Sorted	Dotfiles	Symlinks	What went wrong
tree 2.3.2	yes	hidden unless -a	linked -> src	nothing; prints "8 directories, 11 files"
sed alias (find . -print | sed ...)	no	always shown, including .git/objects	plain name	order is disk order: C.txt, b.txt, a.txt
Super User script wrapping the alias	no	always shown	plain name	script "my docs" splits into my and docs, both "No such file", exit 0
awk version (!/\.$/)	no	always shown	plain name	silently drops trailing.
find . -type d | ls -lARG	ls order	shown	ls -l arrow	ls never reads the pipe

The alias is find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'. It nests correctly, because find lists each directory's contents right after the directory. It does not sort. APFS hands back entries in its own order, so C.txt, b.txt and a.txt came out in that sequence, with node_modules first. On a real project the .git folder alone can run to thousands of lines.

The awk answer uses !/\.$/ to skip the . line for the current directory. That pattern matches any path ending in a dot, so trailing. disappeared without a warning. The last one looks like it filters directories, but ls takes no input from a pipe. I diffed its output against a plain ls -lAR and they were identical, so the find half does nothing.

Two things that change the output without warning

The locale. Look at my\ docs in the right column. My scheduled jobs run in a shell where LANG is empty, which means the C locale. There tree draws ASCII lines, escapes the space with a backslash and prints café.txt as caf\303\251.txt. With LANG=en_US.UTF-8 the same command prints ├── lines and plain names. tree -N prints names as-is in any locale. If a script saves tree output to a file or a prompt, set one of the two so the result doesn't depend on where it ran.

Which find you get. I first ran the alias inside Claude Code's Bash tool (version 2.1.287), and the tree came out wrong: every top-level entry printed first, then all the children hung under src. In that shell find is a shell function that runs a bundled bfs, and its output order differs from /usr/bin/find. type find shows which one you have. Calling /usr/bin/find or command find fixed the nesting. It is another case of an agent's shell not being the shell you think, like the one in Claude Code grep skipping gitignored files.

tree --gitignore matched git, except global ignores

The main reason to prefer the real tree over the alias in a code repo is --gitignore, added in tree 2.0.0 (December 2021, per the tree CHANGES file). I checked it against git on this blog's own repository, which has two .gitignore files:

$ git ls-files | wc -l                          # tracked
1254
$ git ls-files --others --exclude-standard | wc -l   # untracked, not ignored
333
$ tree -a --gitignore -I .git -f -i --noreport -F | grep -v '/$' | wc -l
1587

1,254 + 333 = 1,587, and the sorted path lists had no differences. In a small test repo tree also honored a !keep.log negation, a nested sub/.gitignore, and .git/info/exclude. Two caveats. Without -I .git, tree -a --gitignore lists the whole .git directory, since git never ignores it through a pattern. And tree does not read your global ignore file. With .DS_Store in ~/.config/git/ignore, git hid it and tree showed it. Neither the CHANGES file nor the binary's strings mention core.excludesfile. Two fixes worked:

# 1. hand tree the global file explicitly
tree -a --gitignore --gitfile="$HOME/.config/git/ignore" -I .git

# 2. let git decide, tree only draws
git ls-files -co --exclude-standard | tree -a --fromfile .

The second is exact by construction, because git produced the list. On this repo it printed 1,587 files, the same count. It needs -a, or dotfiles such as .gitignore drop out of the drawing.

The options worth remembering

tree -L 2                         # two levels deep
tree -d                           # directories only
tree -a -I '.git|node_modules'    # dotfiles, minus the noise
tree --dirsfirst -v               # folders on top, 9.log before 10.log
tree -J -L 1 src                  # JSON, for scripts
tree -N --charset=ascii           # stable output for logs and prompts

Since 2.3.0 (January 2026), -I also matches directory names without --matchdirs. tree returns exit 2 when it can't open a directory (tree nope prints [error opening dir]), which is more than the wrapper script managed. Speed is not a reason to pick either. On /opt/homebrew, about 179,000 entries, a warm tree -a took 0.70 seconds and the alias 0.87.

If you can't install anything, the alias can be improved by skipping .git and sorting:

/usr/bin/find . -path ./.git -prune -o -print | LC_ALL=C sort \
  | sed -e 's;[^/]*/;|____;g;s;____|; |;g'

That printed the test folder in tree's order, until I added a file named src.bak. A dot sorts before a slash, so src.bak landed between src and src/lib, and the drawing put src's children under src.bak. It is fine for a quick look. For anything you will paste into a README, a ticket or an AI prompt, install tree. Like watch on Mac, realpath on Mac and xargs on macOS, the shell-only replacement covers the common case and quietly differs on the rest.

Sources: every command ran on 2026-10-03 on a Mac mini (macOS 26.4.1, build 25E253) with tree 2.3.2 from Homebrew, /usr/bin/find, /usr/bin/sed, /usr/bin/awk and git 2.54.0, in throwaway folders under /tmp and in this blog's repository. The version history is from the tree CHANGES file on GitHub, read with the GitHub API. Vote and view counts for the Super User and Stack Overflow questions (359723, 54228819, 1811032) come from the Stack Exchange API on the same day, and the install count from brew info. I did not test MacPorts or any older macOS release.