[BUG] Powershell core support on microshift preset start hints

[adrianriobo]

Recently we added support for powershell core https://github.com/crc-org/crc/pull/3500, with that PR most crc commands detect powershell core and show the right syntax.

With microshift preset at the end of the crc start some commands are shown to help setting the client to interact with the cluster (those commands do not recognize powershell core) so it is showing an incorrect syntax for it:

DEBU SSH command results: err: <nil>, output: pod/routes-controller created 
Started the MicroShift cluster.

export KUBECONFIG="/Users/ec2-user/.crc/machines/crc/kubeconfig"

Use the 'oc' command line interface:
  $ eval $(crc oc-env)
  $ oc COMMAND

[cfergeau]

That's unexpected, this is using shell.GetEnvString https://github.com/crc-org/crc/blob/ec99aaad78d375b500b3bf2521f64810d6519d3c/cmd/crc/cmd/start.go#L264-L280

which handles powershell https://github.com/crc-org/crc/blob/ec99aaad78d375b500b3bf2521f64810d6519d3c/pkg/os/shell/shell.go#L60-L73

[adrianriobo]

yeah you are right...just checking the issue it is a bit more tricky ...if I just log in and open a termianl (powershell or powershell core) it detects it right

Started the MicroShift cluster.

$Env:KUBECONFIG = "C:\Users\crcqe\.crc\machines\crc\kubeconfig"

Use the 'oc' command line interface:
  PS> & crc oc-env | Invoke-Expression
  PS> oc COMMAND

I was running it from an ssh connection which expands the powershell core session, in that case it seems https://github.com/crc-org/crc/blob/ec99aaad78d375b500b3bf2521f64810d6519d3c/pkg/os/shell/shell_windows.go#LL60C3-L60C59 is returning the process for ssh not for the terminal as so noone process name is matching and it is giving me a default

PS C:\Users\crcqe> crc oc-env
export PATH="C:\Users\crcqe\.crc\bin\oc:$PATH"
# Run this command to configure your shell:
# eval $(crc oc-env)

[adrianriobo]

Based on comments this issues seems a bit out of scope, Openshift Local main use case is run it from local, so fixing "issues" related with running it remotely through an ssh session does not seem to be something to take care of.