Get-Process - Missing paths and arguments

In order for get-process to be useful on Linux, it needs to have access to all properties available via ps. Specifically, when ps is called with -f, you get the full path and args called for each process. Unfortunately, on Windows the path has been possible, but the arguments has not been. Most resort to the WMI objects to get this info. Alas, no wmi object on Linux.

Another problem is that the contents of the path property is weird on Linux. It actually shows the real path (unlike ps -f) for a few processes, but then others, it shows no path when there is one. For example, sshd:

10:57:20 PS /home/ubuntu> ps -ef |grep sshd
root      1002     1  0 Aug15 ?        00:00:00 /usr/sbin/sshd -D
root      8325  1002  0 10:19 ?        00:00:00 sshd: ubuntu [priv]
ubuntu    8408  8325  0 10:19 ?        00:00:01 sshd: ubuntu@pts/0
10:57:24 PS /home/ubuntu> gps sshd |select name, path

Name Path
---- ----
sshd
sshd
sshd

And here’s the opposite when it shows a path in gps that is the actual path of the bin running:

10:58:41 PS /home/ubuntu> ps -ef |grep vi
ubuntu    4769  4659  0 Aug15 pts/2    00:00:00 /usr/bin/vi t.py
ubuntu    6183  5897  0 Aug16 pts/4    00:00:00 vi t.py
10:58:43 PS /home/ubuntu> gps vi |select name, path

Name Path
---- ----
vi   /usr/bin/vim.basic
vi   /usr/bin/vim.basic

There doesn’t need to be complete consistency with the formatting, but the property for the process object needs to have the contents of ps somewhere in some property.

This is likely going to be a dotnet issue over a PowerShell one, but it is a story that needs to be addressed by PowerShell in order to become a truly usable shell for Linux.

[felixfbecker]

This seems to be the most common thing googled for Get-Process:

The accepted answer on StackOverflow is to use WMI, which of course doesn’t work on macOS/Linux.

I fully agree that this is a big blocker to making PowerShell become a fully useful shell on Linux/macOS.

[iSazonov]

The issue was fixed in #12288 for Windows and MacOS. For MacOS see #12832.