Unexpected behavior of the new .CommandLine ETS script property on Process objects on Linux

[mklement0]

Sometime after 7.0, a new ETS script property named CommandLine was introduced for System.Diagnostics.Process instances, so that you could query a given process' command line.; e.g.:

# Currently Windows and Linux only: get the PowerShell session's own command line.
(Get-Process -Id $PID).CommandLine

As an aside: The property doesn't yet support macOS - see #13943.

On Linux, this is in effect implemented via the following command, using Linux' special files:

Get-Content /proc/$PID/cmdline 

The problem is that the content of these files contains the verbatim arguments as originally used during process creation separated with NUL characters, which in the terminal - due to NUL getting ignored - presents like directly joined arguments, which is unhelpful to the human observer.

The question is how much effort we want to expend to present a functional command line that is the equivalent of the original:

• A simple solution would be to simply space-concatenate the verbatim arguments -
  (Get-Content /proc/$PID/cmdline) -replace "`0", ' ' - for a friendlier presentation:

  • This results in loss of information: the original argument boundaries aren't preserved.
  • However, it may be good enough for the human observer, and it is what the standard ps utility does with -o command=, which is the only similarly simple solution for macOS - see Make the .CommandLine ETS script property on Process objects work on macOS too #13943.

• Trying to recreate a functional command line would require substantially more effort - namely for recreating required quoting and escaping - and has an inherent conceptual problem:

  • Given that PowerShell syntax differs from that of POSIX-compatible shells: which shell's syntax do you use for the reconstruction? Arguably, it should be PowerShell's (which, of course, is still fundamentally hampered by Arguments for external executables aren't correctly escaped #1995).

Steps to reproduce

On Linux, from PowerShell"

pwsh -noprofile -command 'Get-Content /proc/$PID/cmdline'

Expected behavior

A string with the following verbatim content:

/usr/bin/pwsh -noprofile -command Get-Content /proc/$PID/cmdline

This assumes simple space concatenation without any attempt to recreated required quoting and escaping; see discussion above.

Actual behavior

Since the verbatim arguments are NUL-concatenated, they appear as directly concatenated; note the lack of spaces between pwsh, -noprofile, -command, and the latter's argument:

/usr/bin/pwsh-noprofile-commandGet-Content /proc/$PID/cmdline

Environment data

PowerShell Core 7.1.0-rc.2

[mklement0]

@iSazonov, this issue is unrelated to .NET (it solely relates to an ETS property that relies on native features - see here), so the Waiting - DotNetCore label isn't appropriate.

[iSazonov]

@mklement0 We have [System.Environment]::CommandLine but it is unuseful:

[System.Environment]::CommandLine

"C:\Program Files\PowerShell\7\pwsh.dll" -WorkingDirectory C:\Users\1\Documents\GitHub\iSazonov\PowerShell

There is an issue for this in .Net repository. I hope they will fix this someday. Until then we are forced to use a workaround.

[mklement0]

@iSazonov, whatever improvements may or may not be made to [System.Environment]::CommandLine are irrelevant, as they only apply from inside a .NET process.

Here, we need to be able to find any given process' command line.

There is no good solution to be had here, as an ultimately arbitrary decision must be made as to which shell's syntax to emulate in reconstructing a hypothetical command line - after all, unlike on Windows, there are (fortunately) no process-level command lines on Unix-like platforms, and all a process ever sees is an array of verbatim arguments.

That is, neither a given process nor the system knows what command line of whatever shell was used to launch the process - if a shell was involved at all.

However, given that we're talking about a PowerShell-specific ETS property, it may make sense to transform the array of NUL-separated into a PowerShell command line - but perhaps we should continue the discussion here.

[iSazonov]

@mklement0 The best thing is if we get the .Net API and don't use partial workarounds.
I think it would be more productive to discuss the problem with the .Net team. There is already an issue for that. Now would be a good time since the development of .Net 8 begins.
By the way there is also an issue which is indirectly related to this - allow to rename an exe, e.g. pwsh.exe to pwshw.exe.

[mklement0]

@iSazonov

• The [System.Environment]::CommandLine API doesn't apply to the case at hand, as stated.
• Is there an issue relating to a different API that you have in mind? It would probably have to be [System.Diagnostics.Process]
• Even if there is, there is no shell-agnostic solution to this problem, and even if a .NET solution will eventually be offered via [System.Diagnostics.Process], it's still worth considering a PowerShell-specific solution - which would not be a workaround.

The only shell-agnostic solution would be to report the array of verbatim arguments rather than a single-string command line,:

• Whatever is reported on Windows would be speculative (there is no array of verbatim arguments, because it is up to each process to parse its own process command line and decide how to break it down into arguments)

• It is fortunately readily available on Linux, via /proc/$PID/cmdline

• It is unclear (at least to me) how to obtain it on macOS.

At the end of the day:

• A .CommandLine property can only report a truthful value on Windows.
• A .ArgumentList property (array of verbatim arguments) can only report a truthful value on Unix-like platforms.

Both properties would be useful, on their respective platforms.

The question is whether it's worth implementing cross-platform abstractions, so that you can query .CommandLine also on Unix, and .ArgumentList also on Windows - but these values would be speculative:

• With .ArgumentList on Windows, you could assume the Microsoft C/C++ parsing rules

• With .CommandLine on Unix, you'll have to - ultimately arbitrarily - pick a shell whose syntax to emulate when rebuilding a shell command line from the verbatim arguments. From a .NET perspective, the natural pick would be /bin/sh, i.e. the syntax of a POSIX-compatible shell.

  • The speculative in-process [System.Environment]::CommandLine API in .NET (Core) is currently focused on Windows only, and even there rebuilds a hypothetical command line (even though it could use the WinAPI to retrieve the true command line), namely one based on the aforementioned Microsoft C/C++ parsing rules - which don't work as such on Unix.

/cc @jborean93

[jborean93]

With .ArgumentList on Windows, you could assume the Microsoft C/C++ parsing rules

There is an API that can do this CommandLineToArgv which is the closest you’ll get to an official Windows API to get an array of arguments.

As for the command line string problem on Linux I can easily replicate the behaviour of ps if that’s desired. If the pwsh team prefer things to be quoted that’s also possible but I just want to know what the preference is before doing the work.

[iSazonov]

There is an API that can do this CommandLineToArgv which is the closest you’ll get to an official Windows API to get an array of arguments.

It is used for [System.Environment]::GetCommandLineArgs()