wt --help should print text to terminal, instead of popping open a modal dialog ("Add a CLI executable for interacting with WT")

[pcgeek86]

Description of the new feature/enhancement

When I run the wt command with the --help parameter, a modal dialog is popped up containing the help text. Instead, I would expect that the help text is printed directly to the terminal and immediately returns control to the user.

The modal dialog is visually disruptive to the terminal workflow, as it appears outside the bounds of the terminal window and doesn't match the terminal styling.

Proposed technical implementation details (optional)

n/a

[zadjii-msft]

Oh man, you and me both. As it turns out, this is a Hard problem. If you want more background on why we're stuck in this hellscape, I'd take a look at this doc.

Maybe we could do something silly like wt-help.exe, that's a commandline executable that just does help messages printed to the terminal? I also kinda hate that, so I'm not sure that's a great solution.

There are a few args/commands that really would be best served by a commandline-specifc tool, but we don't have that currently. I'm thinking:

• all the --help commands
• wt --version
• list-profiles

and maybe even in the post #5000 world, there might even be something like

• wt list-windows to show you a list of all the open WT windows and their IDs/titles/PIDs/number of panes/whatever.

I have half a mind to leave this open as "ship a sidecar commandline executable for only doing commandline activities."

Oh there's also #4887

[pcgeek86]

I honestly don't know the codebase, and am not qualified to comment on the proposed implementation. However, I appreciate your interest in improving the UX! 👍 I will be keeping an eye on this thread.

[FallenHoot]

My closed thread is different from this thread but has the same concept. Any update if this will become a feature?

It really is silly to have this MessageBox. Would be great to have something like:
$PSVersionTable.PSVersion
or
cmd --version

My use case:
I want to verify if WT or WT Preview is installed. I also want to know what release version of WT or WT Preview is being used without the MessageBox.

[zadjii-msft]

The idea we've tossed around in meetings before is shipping a totally separate exe, wtc.exe (or something less dumb), that's a SUBSYSTEM=Console executable. That would work well for wt -v, wt --help, and would useful for printing things like, the list of profiles or the list of open windows. It wouldn't be able to actually create new windows though. There's no plan to do that anytime soon though.

There was discussion previously about maybe creating a special manifest entry that would let an application not allocate a console if it didn't have one, but also otherwise act like a SUBSYSTEM=Console application, so that something like cmd.exe would block on it. That was being tracked in #7335, #7337, but that's not going to actually work IIRC.

[KalleOlaviNiemitalo]

Would it work if wtc.exe created a pipe, started WindowsTerminal.exe with the write end of the pipe as stdout, and forwarded the output from the pipe to its own stdout? I hope this would avoid any problems with the GUI process not inheriting a console. By keeping wtc.exe running until the write end of the pipe is closed, this would be somewhat independent of the process model of WindowsTerminal.exe. OTOH, perhaps it needs to wait for the WindowsTerminal.exe process to exit anyway, so that it can forward the exit code.