Is there an execution alias for Terminal Preview?

[devlie]

wt.exe seems to be coupled with the release version only. I'm trying to avoid hardcoding the preview exe path in my script :)

[DHowett]

There is no distinct execution alias for Terminal Preview, as we wanted to make sure that users could opt in for all invocations of wt pointing at one or the other. If your script requires Preview, (1) that's cool! and (2) I'd love to hear about why 😁

In general, whether Preview or Stable is selected was always intended to be an end-user choice.

[DHowett]

Ah! In that case, you might be better served by changing one of the following sets of settings:

• Reconfigure which version of Terminal wt.exe points to
  • Start Menu search for "app execution aliases", and choose "manage app execution aliases"
  • Turn on the one for Terminal Preview, which will turn off the other one for Terminal automatically:
  • 

.. or ..

• Change your default console host to Terminal Preview and change the new instance behavior to "most recent window on current desktop"
  • 
  • 

[devlie]

Thanks, I gave them a try, and they work for start-process cmd.exe but not start-process powershell. I tried changing the default profile to PS5 too, but no dice.

[zadjii-msft]

but not start-process powershell

Hmmm..... that's peculiar. Does doing that open an elevated powershell? Maybe that exe was set to always run as admin?

[devlie]

Hmmm..... that's peculiar. Does doing that open an elevated powershell? Maybe that exe was set to always run as admin?

Sorry, I didn't realize that the privilege matters. I was running Terminal elevated because my ps1 script requires elevation.

Here's the updated outcome:

Privilege	Outcome
Terminal not elevated	Both start-process powershell and start-process cmd open in new tab.
Terminal elevated	Both open in new window.

Is there a way to make it work when elevated?

[zadjii-msft]

Is there a way to make it work when elevated?

There sure isn't - we're working with the platform team to figure that out. It's a Packaged COM issue that we're "tracking" externally in #10276