ps Command on Mac: Why ps -o args Stops at 64 Characters

I started a process with a 300-character command line and asked ps for it in a 200-column terminal. ps -o pid,args gave me 64 characters of the command and stopped, with 130 columns of empty screen to its right. I piped the same command into awk and every character came back. Same binary, same flags, a different answer depending on whether anyone was looking. That was on macOS 26.4.1, and the cutoff has been there since Mac OS X 10.5.

The ps command on Mac is Apple's BSD build (what /bin/ps prints adv_cmds-237), and most of the confusion around it comes from Linux habits: ps aux works, ps -aux does not, nothing with two dashes works, and several common -o keywords do not exist. Below is what I measured on a Mac mini M4, checked against Apple's published source for every adv_cmds version.

Why ps cuts the command short

A background sleep was started with a 306-character argv[0], and each command ran once in a real terminal (a tmux pane driven through script, at 200 and then 100 columns) and once into a pipe. The number is the length of the output line:

Three separate rules produce that table, and all three are in print.c and ps.c:

• A pipe means unlimited. ps.c sets the width to unlimited when isatty(STDOUT_FILENO) is false, under an Apple bug number comment (/* 3862041 */). -f does the same unconditionally (/* 4990408 */), which is why ps -ef never truncates. In a pipe, COLUMNS=80 changed nothing; the isatty check comes after it.
• args is capped at its column width on a terminal. The args() printer passes a no_trunc flag of 1, and when output is a terminal that flag makes the last column print exactly its default width, 64, instead of filling the screen. command passes 0 and fills the screen. One -w only raises the screen width to at least 131, which args ignores. -ww is the only flag that frees it.
• A command column that is not last is always 64. Put args before another column and it prints %-64.64s, terminal or pipe, -ww or not.

To date it, I joined Apple's 29 adv_cmds tags to the 166 tags of distribution-macOS by submodule commit. The args keyword, its 64 width and the isatty rule all first appear in adv_cmds-118, which shipped in Mac OS X 10.5.0. From 10.5 through macOS 26.5 that is 115 releases with identical behavior. The 48 releases from 10.0 to 10.4.11 ran older ps code with no args keyword at all, and three early 10.0.x tags have no adv_cmds entry.

Linux ps commands that fail on Mac

I ran the usual Linux forms against /bin/ps. Most fail loudly. Two fail in a way a script will not notice:

The -eLf case is quiet because -L on macOS means "list keywords", so you get 88 keyword names instead of threads and a success code. The -o case is worse in a pipe: ps -o pid,cmd -p 1 | wc -l printed 2, the pipeline's exit status was 0, and the only clue was a warning on stderr. Anything parsing that output gets a column of PIDs and no commands.

Two more defaults differ. ps aux on Mac sorts by CPU, because the man page says -u "implies the -r option"; Linux sorts by PID. And the comm keyword prints the full executable path here (/sbin/launchd), where Linux prints a 15-character name. The short name on Mac is ucomm, 16 characters.

Which -o keywords exist on both

ps -L lists 88 keyword names on this machine, aliases included. I compared them with the keywords in the procps-ng ps(1) manual. 48 names exist on both, among them pid ppid pgid user uid %cpu %mem rss vsz etime lstart stat tty comm args command. 40 exist only on macOS (pagein, wq, usrpri, xstat and others). The Linux names I see in scripts that macOS rejects: cmd, etimes, sz, rsz, psr, pgrp, sid, tid, nlwp, euid, exe and start_time. For etimes (seconds since start) the closest Mac keyword is etime, which prints 18-08:01:10 style and has to be parsed.

Installing GNU ps is not an option. Homebrew's procps formula declares depends_on :linux, because procps reads /proc, which macOS does not have. That is the honest answer to the Ask Different question Can I use GNU ps on OS X? (8,122 views).

What people trip over

I pulled every question with "ps" in the title from Ask Different, and the macOS-tagged ones from Stack Overflow, Super User and Unix & Linux, through the Stack Exchange API: 94 results, about half of them PostScript or PlayStation noise. The top-voted real one is a Linux flag: Linux ps f (tree view) equivalent on OSX, 141 votes and 85,924 views. Next come the modern equivalent of ps aux on macOS Sierra (31,499 views) and "ps aux" works but "ps -aux" doesn't (15,674 views). Selecting processes by command name is the missing -C, which pgrep replaces.

One that I reproduced by accident: ps grep for a process with an umlaut. My scheduled jobs run with no LANG set, and in that environment ps printed a process named sleep-café-한글 as sleep-cafM-CM-)-M-mM^UM^\…, so ps -o args= | grep café matched 0 lines. With LC_ALL=en_US.UTF-8 (or just LC_CTYPE=UTF-8) it matched 1. The question's output shows the same M- escapes; its accepted answer points at a second trap, decomposed Unicode in file paths, and recommends pgrep -f. Under launchd or cron, set a UTF-8 locale before you grep ps.

Finally, ps -E (show environment) printed nothing extra for my own child process started with FOO_PROBE=1; on 26.4.1 the environment is not readable that way. If you are debugging what a job inherited, launchctl setenv not working covers how I check it with a file instead. For a live, sortable view rather than a snapshot, see htop equivalents for Mac.

FAQ

How do I see the full command in ps on Mac?

Use ps -ww, for example ps -ww -o pid,args or ps auxww. In a terminal, the args keyword stops at 64 characters even with a single -w, and the command keyword stops at the window edge. Piping ps into another command, or using ps -ef, prints the full command line without any flag.

What is the difference between ps aux and ps -ef on Mac?

Both list every process, 708 on the Mac mini I tested. ps aux uses BSD columns (USER, %CPU, %MEM, VSZ, RSS, STAT) and is sorted by CPU usage; ps -ef uses UID, PID, PPID, STIME and CMD, is sorted by terminal and PID, and never truncates the command. ps -aux with a dash fails on Mac with "No user named 'x'".

How do I sort ps output by memory on Mac?

Use ps aux -m, or ps -A -m -o pid,rss,comm for a narrower list. macOS ps has no --sort option; -m sorts by memory and -r sorts by CPU. RSS is in kilobytes.

How this was checked: every command ran on 2026-10-16 on a Mac mini M4 with macOS 26.4.1 (25E253) against /bin/ps, which what(1) reports as adv_cmds-237 and which is setuid root on this install. The width table used a background sleep renamed with exec -a to a 306-character argv[0]; terminal rows ran inside a detached tmux pane through script(1) with stty cols set to 200 and 100, pipe rows ran through sed and awk, and the numbers are line lengths, not screenshots. The release mapping joins the 29 apple-oss-distributions/adv_cmds tags to the 166 distribution-macOS tags by the adv_cmds submodule commit, then checks ps/print.c, ps/ps.c and ps/keyword.c in each version (ps.tproj before adv_cmds-138.1). The keyword comparison is the output of ps -L against keyword names parsed from the man7.org procps-ng page, single letters and AIX % codes excluded, so a keyword documented only elsewhere would be missed. Stack Exchange titles, votes and views came from the Stack Exchange API the same day. Demand for this topic came from Google autocomplete, where "ps aux command mac" was the most frequent completion.