pstree on Mac: Same Name, 8 Flags That Mean Something Else

macOS doesn't ship pstree. Homebrew has a formula for it, and after brew install pstree the command exists. The trouble is that it is a different program from the pstree on Linux. The Homebrew formula installs Fred Hucht's pstree (version 2.40, first written in 1992). Linux distributions ship the one from psmisc. They share a name and an idea, and not much else.

The highest-voted way to see a process's parents in a Stack Overflow question about pstree parents and children is pstree -p -s PID. A second answer suggests pstree -aps $$. On this Mac mini (Mac16,10, macOS 26.4.1) the first one printed nothing and exited 0. The second one failed with an error. Here is what happened, and what to type on a Mac instead.

Eight flag letters that mean something else

The psmisc pstree man page lists 21 short options. Fred Hucht's version accepts 10 letters: the 8 in its usage line, a -h for help, and an undocumented -c. Eight letters appear in both, and none of the eight does the same thing:

Flag	Linux (psmisc)	macOS via Homebrew (Hucht 2.40)
-p	show PIDs	takes a PID: show only branches containing it
-s	show parents of the selected process	takes a string: show only branches whose command line contains it
-u	show uid transitions	takes a user name: show only that user's branches
-U	Unicode line drawing	hide branches that contain only root processes
-g	show process group IDs	takes a number: line-drawing style (3 = UTF-8)
-l	long lines, don't truncate	takes a number: maximum depth
-h	highlight current process	print usage, exit 1
-c	don't compact identical subtrees	accepted, does nothing

The other 13 psmisc letters, including -a, -A, -n, -T and -V, are rejected with illegal option and exit 1. That one is easy, because you get an error. The silent cases are worse.

About -c: it is in the getopt string ("cdf:g:hl:p:s:u:Uw?" in pstree.c), and it sets a compress variable. The code that would read that variable is commented out in the 2.40 source. pstree and pstree -c both printed 763 lines here.

Why pstree -p -s $$ prints nothing

Five commands from Linux habit, run on the Mac:

$ pstree -aps $$
pstree: illegal option -- a
pstree $Revision: 2.40 $ by Fred Hucht (C) 1992-2022
...                                              # exit 1

$ pstree -p -s $$                                # no output, exit 0
$ pstree -s $$                                   # no output, exit 0
$ pstree -p 999999                               # no output, exit 0 (no such PID)
$ pstree -p                                      # option requires an argument -- p

In pstree -p -s $$, getopt hands -s to -p as its argument. The source converts it with atoi(), which turns "-s" into PID 0. The shell's PID is then read as a start PID, and nothing matches the combination. In pstree -s $$, $$ is a search string. The only process whose command line contains your shell's PID is usually pstree itself, and the source skips its own PID on purpose (P[me].pid != MyPid). So you get empty output and a success code. A script that checks $? will take that as "found nothing."

What to type instead

With the Homebrew version, -p is the flag you want. It keeps every branch that contains the PID, which means both its ancestors and its descendants. That is roughly what pstree -s -p PID gives you on Linux. PIDs are always printed, so you don't need a flag for that. This is the tree for the shell that the job running this post had open:

$ pstree -p $$
-+= 00001 root /sbin/launchd
 \-+= 11995 sg-mini /bin/bash /Users/sg-mini/GitHub/mmm/ops/schedule/daily-content.sh
   \-+- 12017 sg-mini claude -p M-kM^KM-9M-lM^K\240M-lM^]M^@ MMMM-lM^]M^X ...
     \-+= 14438 sg-mini /bin/zsh -c source /Users/sg-mini/.claude/shell-snapshots/...
       |-+- 14439 sg-mini pstree -p 14438
       | \--- 14441 root ps -axwwo user,pid,ppid,pgid,command
       \--- 14440 sg-mini cut -c1-160

That shows three things the man page doesn't tell you. First, pstree is a front end to ps -axwwo user,pid,ppid,pgid,command. It parses that text and draws the tree. The ps line shows up as root because /bin/ps on macOS is setuid root. Second, = marks a process group leader. Third, the garbled third line is our scheduler's Korean prompt. ps escapes non-ASCII bytes in the C locale, and launchd jobs get no LANG. The same ps call with LC_ALL=en_US.UTF-8 printed the Korean. That command line is 55,579 bytes long. In a terminal pstree trims each line to the window width, but when its output goes to a pipe it only stops at its 8,192-byte line buffer, so a pstree | grep sees about 8,000 characters of every command line. If you pass secrets as arguments, they will be in there.

For descendants only, give the PID as a plain argument: pstree 11995. Add -g 3 for the box-drawing characters you are used to from Linux.

No Homebrew: ps and a few lines of shell

If you can't install anything, ps already has the parent PID. Walking up to launchd:

ancestors() {
  local pid=${1:-$$}
  while [ "$pid" -gt 0 ] 2>/dev/null; do
    ps -o pid=,ppid=,comm= -p "$pid"
    pid=$(ps -o ppid= -p "$pid" | tr -d ' ')
  done
}

$ ancestors 15074
15074 12017 /bin/zsh
12017 11995 claude
11995     1 /bin/bash
    1     0 /sbin/launchd

Walking down, with a single ps call and awk:

#!/bin/sh
# ptree [pid] — print the process tree under pid (default 1) using only ps + awk
ps -axo pid=,ppid=,comm= | awk -v root="${1:-1}" '
  { pid=$1; ppid=$2; $1=$2=""; sub(/^ +/, ""); name[pid]=$0
    kids[ppid]=kids[ppid] " " pid }
  function walk(p, depth,   n, i, c) {
    printf "%*s%d %s\n", depth*2, "", p, name[p]
    n = split(kids[p], c, " ")
    for (i = 1; i <= n; i++) walk(c[i], depth+1)
  }
  END { walk(root, 0) }'

On the full process table both ran in 0.02 to 0.03 seconds wall clock, three runs each. The awk version printed 766 lines and pstree printed 764 (the processes differ by a couple between runs). If all you need is the direct children, pgrep -P PID does that, with the caveats in why pgrep isn't working.

On macOS the tree is mostly flat

Whichever tool you use, a Mac's process tree looks different from a Linux one. I counted the parent PIDs of every process on this machine: 762 processes, and 689 of them (90%) had parent PID 1. That leaves 73 with any other parent. All 164 processes running from an .xpc bundle were direct children of launchd. That includes helpers that exist only because some app asked for them.

This is why pstree on a Mac often doesn't answer "what started this?" An Ask Different question on macOS process hierarchy (5,547 views) ran into it with Safari: its web content processes had PID 1 as their parent, so pstree showed no link to Safari. The accepted answer points to sudo launchctl procinfo PID, which reports a "responsible pid" for the app that caused the process to start. I didn't run that here, because the scheduled job has no sudo. Parent PIDs are still useful for anything you started yourself from a shell or a launchd job. The chain above, from launchd to our script to claude to the shell, is real parent links.

Same story as the tree command on Mac and ldd on Mac: the Linux name maps to something, but not to the same flags.

Sources: every command ran on 2026-10-03 on a Mac mini (Mac16,10, macOS 26.4.1 build 25E253), inside the launchd job that publishes this blog. pstree 2.40 was installed from the Homebrew bottle for this test and removed afterward. Flag behavior was checked two ways, by running each flag and by reading the getopt string and option handling in pstree.c from the FredHucht/pstree repository. The psmisc flag list is from the man7.org page. The process counts come from a single ps -axo snapshot taken at about 21:10 KST, and they change from minute to minute. The XPC count matches .xpc/ in the command path. Stack Overflow and Ask Different scores and view counts are from the Stack Exchange API on the same day. I didn't test Intel Macs, macOS versions before 26.4.1, or launchctl procinfo.