Clone wiki

psi / ProcArgsExe

Process names, arguments and executables

There are a number of attributes of Process class describing the command and it's arguments. Some of them are always available while others might not be depending on the system and/or privileges PSI has. This page tries to explain the difference between the attributes and when you can expect them to be present.

As a quick summary, the following attributes will always have meaningful values that you can use:

  • Process.command

More detailed information, but not always present is available in these attributes:

  • Process.argc
  • Process.exe
  • Process.args

This attribute is guaranteed to be present on all platforms and for all processes. When the system supports an "accounting name" this will be the value used (Linux, Darwin). Otherwise it will be set to the basename of the executable. By now most systems will have a valid value for this attribute.

However if the executable is not known either, e.g. kernel threads, the platform implementation will try to find an equivalent name since this has to be present.

Note that for zombie processes this can be an empty string.


This is a string containing as much from the command line of the process as possible. It will be present on all systems for all processes, anything that is present as a process (including kernel threads or LWPs etc) will have some string to put here.

This is useful on systems like SunOS where a string of the command line is always available up to a fixed length, but where access the full argument list depends on the privileges.

Sometimes an implementation will only have an empty string for this (possible on Linux for example) in which case the same value as will be used.

Note that for zombie processes this can be an empty string.

(Implementation note: If this is set to an empty string the core PSI code will ignore it and use so no need to do this in an arch implementation.)


This is simply an integer of the number of arguments provided to the process. On Darwin you need the right privileges to get this, on all other platforms it will always be available.

It's main reason of existence is that on SunOS you will always know this value, but not always have Process.args available. Using this you can then know if Process.command contained everything or was chopped off.


This is the absolute path of the executable, if possible. Next best thing is the basename of the executable (e.g. Solaris 8 and 9, or Solaris 10 with insufficient privileges). Generally kernel threads or kernel LWPs will not have an executable and thus this could be an empty string, but accessing this attribute should never raise an exception.


This is a list of the full arguments to the process. On all systems this is the argument vector as present in memory of the process, so if a process modified its argument vector before the object got instantiated this change will be visible here.

On some systems (Solaris) this information is not exposed by the kernel directly and must therefore be read directly form the address space of the process. Obviously being able to do this depends on the privileges PSI has to read the other process. This might also be missing from kernel threads of kernel LWPs on some systems.