6

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

USER       PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
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?

Peter Mortensen
  • 2,318
  • 5
  • 23
  • 24
knorv
  • 1,799
  • 6
  • 19
  • 29
  • I just posted a detailed answer for this under another question: https://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 04 '22 at 23:38

5 Answers5

8

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".

DictatorBob
  • 1,644
  • 11
  • 15
7

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.

Glorfindel
  • 1,213
  • 4
  • 15
  • 22
Dan Carley
  • 25,617
  • 5
  • 53
  • 70
0

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
KJ7LNW
  • 151
  • 3
-1

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

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

kmarsh
  • 3,103
  • 16
  • 22
  • Check question #2 about procfs. – Dan Carley Sep 04 '09 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`. – Peter Mortensen Nov 20 '20 at 05:03
-1

Extract all process ids and full path from /proc:

ls -l /proc/*/exe 2>/dev/null | awk '{print $8 " " $10}'
Peter Mortensen
  • 2,318
  • 5
  • 23
  • 24
Klaus Hartnegg
  • 331
  • 1
  • 7