PowerShell argument WindowStyle -Hidden is not respected when the default terminal application is Windows Terminal

[sachinjoseph]

Windows Terminal version

1.12.10393.0

Windows build number

Microsoft Windows NT 10.0.22549.0

Other Software

Software	Version
PowerShell.exe	Multiple Versions
pwsh.exe	Multiple Versions

Steps to reproduce

1. Set Windows Terminal as the default terminal application:
   .
   

2. Make sure to save changes to Windows Terminal Settings, and then using Windows Run, run pwsh -WindowStyle Hidden -Command Sleep 10:
   

Expected Behavior

A new PowerShell process launches (Windows Terminal), and it isn't visible. The window may flash for a second. PowerShell window shouldn't be displayed when it's launched with WindowStyle -Hidden.

Actual Behavior

A new PowerShell process launches (on Windows Terminal), and it is visible and remains visible (and waits) for 10 seconds.

Note: There is no repro for this issue with Windows Console Host as the default terminal application.

[zadjii-msft]

PowerShell/PowerShell#3028 looks like it's related. This probably requires quite a bit of thinking...

[malxau]

Dustin wrote a spec for this a while back that doesn't seem to have ever been merged:

#7337
https://github.com/microsoft/terminal/blob/ec27049553e9ca2135068edf8a9946a9d94ae2c4/doc/specs/%237335%20-%20Console%20Allocation%20Policy.md

Looking at it now the odd part is asking console processes to call ShowWindow. That doesn't seem to fit well with what Terminal is trying to do w.r.t. multi-tab, multi-pane, etc.

[sachinjoseph]

PowerShell/PowerShell#3028 looks like it's related. This probably requires quite a bit of thinking...

The console window being shown for a second may still be tolerable but with WT the window isn't hidden at all - there's no difference between using the PowerShell argument -WindowStyle Hidden and not using this argument when WT is the default terminal application.

[sachinjoseph]

This is a blocker for many applications such as rush that use PowerShell to run background tasks. Rush issue tracked here.

[fantesykikachu]

just to note, Terminal also doesn't allow the old vbs script trick.
CreateObject("WScript.Shell").Run <batch script>, 0
with conhost this would run the batch script but no window is shown both on screen and on the taskbar.
however with Terminal as the process that runs batch scripts, the script runs but the terminal window is shown.

[DHowett]

It looks like the windowing work done in 1.14 fixed the PowerShell case, but we still have #12154 to consider.

[HenryBaby]

Did this break again somewhere along the way?
Tested on version 1.15.2713.0.

[KG-droid]

Did this break again somewhere along the way? Tested on version 1.15.2713.0

Yeah I've just updated to 1.15.2875.0 and still getting this issue

[zadjii-msft]

I'm gonna lock this thread for a bit to give everyone some time to relax. Obviously, this is still busted (at least, for Powershell 7 pwsh, though, it seems to work for powershell.exe). You'll note, there's plenty of issues on this repo that are even older than this one. We do our best to fix as many issues as we can, but if this is one that you're particularly passionate about, we'd love to hear suggestions on how to fix it. The Terminal (and PowerShell) are open-source after all ☺️

[fubaWoW]

it seems to work for powershell.exe

NO it does not...
The Terminal Window just "minimize" but is not "Hidden" as intended!

with the "default" console both of this work:
powershell -WindowStyle Hidden -Command Sleep 10
AND
pwsh -WindowStyle Hidden -Command Sleep 10

[KG-droid]

Yeh confirmed it just minimises it. I have found what seems to be a work around though:

$script:showwindowAsync = Add-Type -memberDefinition @"
[DllImport ("user32.dll")]
public static extern bool ShowWindowAsync(IntPtr hWnd, int nCmdshow);
"@ -name "Win32ShowWindowAsync" -namespace Win32Functions -passThru

$showwindowAsync: : ShowWindowAsync( (Get-Process -id $pid).MainWindowHandle, 2)

If you add that to the start of your scripts it hides the window via win32api. At least then you don't have to just disable Windows Terminal in your organisation to get around this. Although that said it depends how many scripts you have that run as the user, if it's pheasable to add that script to all of them.

[fubaWoW]

Yeh confirmed it just minimises it. I have found what seems to be a work around though:

$script:showwindowAsync = Add-Type -memberDefinition @" [DllImport ("user32.dll")] public static extern bool ShowWindowAsync(IntPtr hWnd, int nCmdshow); "@ -name "Win32ShowWindowAsync" -namespace Win32Functions -passThru

$showwindowAsync: : ShowWindowAsync( (Get-Process -id $pid).MainWindowHandle, 2)

If you add that to the start of your scripts it hides the window via win32api. At least then you don't have to just disable Windows Terminal in your organisation to get around this. Although that said it depends how many scripts you have that run as the user, if it's pheasable to add that script to all of them.

Yeah, many thanks for that, i already use a C# app for hide console if needed, but...
As of this is a Bug-Report (Issue Tracker) for "Windows Terminal" and the BUG still exists, it is not my point "how to workaround", but thanks anyway!

It's still bugged in "Windows Terminal" and so it is up to them to fix this in the Terminal Code!
Especially as of this is a "Feature" used and working PROPERLY in the default Terminal but it is NOT in "Windows Terminal" and exactly THAT is the point of this Bug-Report!

You can Block me or set anything to Off-topic as often as you want...
But this will NOT fix the (1+ Year old) Bug, it still exists and is not working with powershell.exe nor is it on pwsh.exe, that is REALITY not not a problem with Powershell at all!

[DHowett]

Hey @zadjii-msft! Now that we merged tearoff plus #14944 and #13478, we might have the right underpinnings to let console applications "hide" their windows.

Mini-proposal (which should be fleshed out into a spec):

A console application that hides its window should be detached from the pane/tab it's in and moved to a new tab in a hidden window. That window can show up in the tray icon list of windows, and users can show them if they want, but we won't have to present UI for it. If that console app was already the only tenant in a window (no panes/tabs), we could just mark that one hidden.

[zadjii-msft]

That's the first real proposal to SW_HIDE that makes sense to me for a tabbed application.

Though, here's a possible problem:

• user runs foo.ps1 BUT NOT FROM DEFTERM so closeOnExit is set to graceful
• foo.ps1 hides the window
• does it's buisiness
• exits with error
• oh noes, the terminal is now hidden and just chillin and the user can't restore it to close it

so we'd need to special case that too

[KG-droid]

Hey @zadjii-msft! Now that we merged tearoff plus #14944 and #13478, we might have the right underpinnings to let console applications "hide" their windows.

Mini-proposal (which should be fleshed out into a spec):

A console application that hides its window should be detached from the pane/tab it's in and moved to a new tab in a hidden window. That window can show up in the tray icon list of windows, and users can show them if they want, but we won't have to present UI for it. If that console app was already the only tenant in a window (no panes/tabs), we could just mark that one hidden.

Hi DHowett
When you say "That window can show up in the tray icon list of windows", do you mean a user would be able to just click the icon in the tray/taskbar icons and re-open the hidden window? As ideally from a business point of view, you wouldn't want users to be able to see and mess with hidden windows that easily, that are configuring things, as inevitably, some users would end up closing it, and then end up logging incidents because something is no longer working.

[MV10]

Request: Since all SW_HIDE related-issues get closed as duplicates of this thread, perhaps change this issue title to something not so Powershell-specific?

DHowett's idea makes the most sense to me: Hide the tab, and I'm with KG-droid, if we wanted users to mess with the window, we'd minimize it.