Michael Klement

> `pwsh` seems to have added a directory to the start of `$env:PATH` `pwsh` - by design - _prepends its own installation directory (`$PSHOME`) to `$env:PATH`_, presumably in an effort...

As a data point: on _macOS_ on an M1+ machine, `dotnet tool install -g PowerShell` correctly installs an ARM64 binary.

You're correct: It is only the _stub_ binary that is ARM. The executable ultimately invoked - `$HOME/dotnet/tools/.store/powershell/7.4.4/powershell/7.4.4/tools/net8.0/any/unix/pwsh` - is indeed an x86-64 executable.

@rdebath, it may be a full executable, but, as I've just discovered, it delegates first to `$HOME/dotnet/tools/.store/powershell/7.4.4/powershell/7.4.4/tools/net8.0/any/Microsoft.PowerShell.GlobalTool.Shim.dll` and then to `$HOME/dotnet/tools/.store/powershell/7.4.4/powershell/7.4.4/tools/net8.0/any/unix/pwsh.dll` - at least on my Mac: * If you...

Thanks for the background info, @rdebath. Yes, the kernel, based on shebang line `#!/usr/bin/env pwsh`, picks the first `pwsh` binary in `$env:PATH` (via `/usr/bin/env`). Because of the way the `$HOME/dotnet/tools/pwsh`...

> I don't like the idea of putting the Dotnet tools directory in front, it would interfere with the user putting override "stuff" in $HOME/bin for tools other than pwsh....

> Actually it looks like Windows ARM has an i386 emulator turned on by default so you can use the x86 version. That doesn't work for me in my VM...

I don't have access to that and I don't know what you mean by _32bit intel C++ version of the shell script_, but it's also not clear how that would...

😁 No worries re rabbit hole; as noted, it's been a learning experience for me. As for how to frame the issue at hand: * The .NET tool-installed PowerShell version...

Turns out I reported this problem 4+ years ago, albeit macOS-focused and with less technical insight - issue was closed due to inactivity: * #12205 Another closed-due-to-inactivity issue with the...