--window argument doesn't work when used in startupActions

[Sophismata]

Windows Terminal version (or Windows build number)

1.9.1942.0

Other Software

No response

Steps to reproduce

1. Set the startupActions in settings.json to "--window example"
2. Start wt.exe without arguments
3. View the window title with the identifyWindow command

Expected Behavior

Window title should be example.

Actual Behavior

Window is untitled (<unamed window>).

Note that using the --window argument outside of startupActions works fine.
Also, executing wt --window example as a startupAction also works. If you double-escape semicolons you can create named windows by abusing that.

Example:
wt --window secondWindowName new-tab --profile firstTabSecondWindow \\; new-tab --profile secondTabSecondWindow ; new-tab --profile firstTabFirstWindow ; focus-tab --target 0

Creates:

1. An unamed window with one tab using the firstTabFirstWindow profile.
2. A named window, secondWindowName, with two tabs, using the profiles firstTabSecondWindow and secondTabSecondWindow.

[elsaco]

@Sophismata what is the correct way to add startup actions?

Here's an example:

"startupActions": "wt -w FirstWindow"

will launch a new window titled FirstWindow.

"startupActions": " -w FirstWindow"

will end up throwing [error 0x80070002 when launching `-w FirstWindow']

These are some comments from AppCommandLine::ParseCommands() method:

//   - In AppCommandlineArgs::BuildCommands, we'll make sure each
//     subsequent command in a single commandline starts with a wt.exe.
//     Our very first argument might not be "wt.exe", it could be `wt`,
//     or `wtd.exe`, etc. Regardless, we want to ignore the first arg of
//     every Commandline

Is what's being added to "startupActions" a subsequent command? Thx!

[Sophismata]

@elsaco that's actually a surprisingly good question. At first I thought it was straightforward — the startupActions setting is a string containing the command line parameters to use by default, when none are supplied to wt.exe.

But strictly speaking, according to the docs and the schema, it's a "list of actions to execute on startup," in "the same format as commands in the command line arguments."

And the command line arguments options and commands section clearly delineates between --window as an option, and (e.g.) new-tab as a command.

So, I don't think this is technically a bug. But it is potentially unclear. From my perspective, I've been treating the setting as a sequence of command line paramters, and up until the inclusion of the --window option that was effectively the same as a sequence of commands. Out of the options available, --help would have broken things, and --maximised, --fullscreen, and --focus all have other settings available within settings.json to configure them.

The fact that wt even works as a command within startupActions is technically a bug, too, at least according to the documentation.

Finally, my actual objective here is to create a named window on startup, so that it can be summoned and dismissed with the globalSummon action. It's not necessary for that functionality to come from startupActions. The other command line options are fulfilled via the launchMode setting.

So, in summary:

1. I think the documentation for startupActions should be clarified to reflect its intended behaviour. I'm happy to submit a PR for this, assuming the intended behaviour is agreed on.
2. There should be a setting to customise the window name(s) on startup.
   • Failing that, a window profile (and a command to call it) might work better. Something along the lines of Add per-window-name global settings #9992.

Edit: Actually there's a lot of customisation available via actions. Including for new windows and new tabs. It might be more straightforward, and customisable, to extend the ability to name actions — allowing them to be hidden from the command palette, if desired — and then create a wt.exe command that allows you to call an action by name. invoke-action, use-action, or something along those lines. Should largely capitalise on functionality already present while enabling a lot of configuration. And you'd have the benefit of being able to call specific actions via the command line.

[zadjii-msft]

At first I thought you were looking for #10146, but after reading your follow up, I'm gonna say that your actual ask will be covered by some combo of #9992 and #9994

/dup #9992
/dup #9994

Thanks!

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[Sophismata]

@zadjii-msft #10146 was definitely what I was angling towards originally. If options aren't supposed to be allowed in the startupActions setting though, #9992 and #9994 work great as replacements for the desired functionality. Cheers 🙂.