Consider the following lines from a "ps auxwww" output:

root      4262   0.0  0,1    76592   1104 s005  Ss   10:02am   0:00.03 login -pf yo
yo        4263   0.0  0,0    75964    956 s005  S    10:02am   0:00.03 -bash

How do I force ps to expand all commands in the COMMAND column to their fully qualified path names? I want login to be resolved to /usr/bin/login and Bash to /bin/bash.

Is there an equivalent to procfs in Mac OS X? That is - is there a file-based mechanism to easily obtain process information?

  • I just posted a detailed answer for this under another question: stackoverflow.com/a/74681783/2058184. Didn't want to post a duplicate answer here, but it applies to this question as well, because none of the answers involving ps or /proc are sufficient on MacOS. Hope it helps!
    – grnch
    Dec 4, 2022 at 23:38

5 Answers 5


Try this instead:

ps ax -o pid,cmd

You can reformat it as you wish (read the man page for details).

Finally, I think that ps (and even cat /proc/*/cmdline) will report the command the way it was launched. So if no full path was given, it will appear as just "command" instead of "/path/to/command".

  • 6
    Close! On OS X and FreeBSD (and probably other BSD-based systems) it's "ps axwww -o pid,command". Sep 4, 2009 at 17:07

Firstly, processes can change the title reported by ps, so it's not very reliable in itself. You could try the environment variables using the 'e' flag.

ps auxwwwe

Within these should be a builtin '_' variable as described here.

For every command that is run as a child of the shell, sh sets this variable to the full path name of the executable file and passes this value through the environment to that child process.

This holds true for sh on BSD as it does Linux. I believe that this can't overwritten by the user. However, its availability may depend on the user's choice of shell, it's pretty nasty and your mileage may vary.

OS X doesn't have a native procfs. There is a port based upon FUSE. Details can be found here. Again, your mileage may vary.

  • 1
    Ewwww ! Sep 4, 2009 at 12:41
  • The (last) link is broken (404). (However, the OP has left the building.) Nov 20, 2020 at 5:07

Those referencing /proc/<pid>/exe are on the right track, ps doesn't provide exe paths reliably. This example provides a list of PIDs and binary paths for some USER. Note that this may be Linux-specific, as I don't have an OSX system to test with:

# pgrep -u USER | while read a; do echo -n "$a "; readlink /proc/$a/exe; done
2439 /usr/bin/gnome-keyring-daemon
2442 /usr/bin/mate-session
2470 /usr/bin/dbus-launch
2471 /usr/bin/dbus-daemon
2481 /usr/bin/ssh-agent
2510 /usr/libexec/dconf-service
2520 /usr/libexec/mate-settings-daemon
2528 /usr/bin/marco
2532 /usr/bin/mate-panel
2537 /usr/libexec/gvfsd
2542 /usr/libexec/gvfsd-fuse
2554 /usr/bin/pulseaudio


Stop messing around with ps and use cat /proc/pid/cmdline .

You can use wildcards such as /proc/*/cmdline .

  • Check question #2 about procfs.
    – Dan Carley
    Sep 4, 2009 at 12:39
  • This does not display the fully qualified path name (in all cases), only how it was launched. For example, if the Python 3 interpreter was launched as python3 in a terminal window and its PID was 5981, then cat /proc/5981/cmdline would display python3. Nov 20, 2020 at 5:03

Extract all process ids and full path from /proc:

ls -l /proc/*/exe 2>/dev/null | awk '{print $8 " " $10}'
  • Sample output of ls -l /proc/5981/exe is: lrwxrwxrwx 1 embo embo 0 Nov 20 05:25 /proc/5981/exe -> /usr/bin/python3.8 Nov 20, 2020 at 5:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .