Said package is meant to be installed with dotnet tool install [-g], i.e. as a .NET tool.

Invoked as such - by name only via $env:PATH rather than by full, package-internal path (which should be considered an implementation detail) - it does have a macOS-appropriate CLI entry point.

However, there is a problematic aspect, after all:

• [Fixed with the PR that fixed the issue below] PowerShell installed as a .NET global tool cannot invoke its own CLI on macOS #12205
• [While the associated PR fixes the above, there are still problems] Pwsh corrupts PATH environment variable, breaking nested invocations on everything that isn't x86-64 #24090

Said package is meant to be installed with dotnet tool install [-g], i.e. as a .NET tool.

Invoked as such - by name only via $env:PATH rather than by full, package-internal path (which should be considered an implementation detail) - it does have a macOS-appropriate CLI entry point.

However, there is a problematic aspect, after all:

• [Fixed with the PR that fixed the issue below] PowerShell installed as a .NET global tool cannot invoke its own CLI on macOS #12205
• [While the associated PR fixes the above, there are still problems] Pwsh corrupts PATH environment variable, breaking nested invocations on everything that isn't x86-64 #24090

Thanks for the explanation about the intended usage and installation.

However, as #12205 shows and as mentioned in the error details, there is no macOS executable in the NuGet whatsoever. The "unix" executable is on the ELF (Executable Linux File) format.

When you install PowerShell as a .NET tool globally, a macOS executable is placed in $HOME/.dotnet/tools, which serves as the entry point.

You can verify this with file $HOME/.dotnet/tools/pwsh

#12205 is about the value of $PSHOME pointing to a directory whose pwsh file is indeed a x86-64 Linux one, but this is only a problem if you invoke it directly. #24090 has more details. The - arguably problematic - fix via PR #24228 will be to make $PSHOME point to $HOME/.dotnet/tools

My understanding is that when run as a dotnet tool is uses the pwsh.dll rather than pwsh. Where this fails is when you try and run pwsh from the PATH with a script run by the powershell tool.

What is more important is that the libSystem.IO.Ports.Native.dylib, libSystem.IO.Ports.Native.so, libpsl-native.dylib and libpsl-native.so exist under the correct runtimes tree.

So pwsh.dll is not CPU specific but the lib*.so and lib*.dylib are.