Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fails to launch maximized/fullscreen and the given profile #7318

Closed
Guiorgy opened this issue Aug 17, 2020 · 5 comments · Fixed by #8315
Closed

Fails to launch maximized/fullscreen and the given profile #7318

Guiorgy opened this issue Aug 17, 2020 · 5 comments · Fixed by #8315
Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal Backlog

Comments

@Guiorgy
Copy link

Guiorgy commented Aug 17, 2020 •
edited
Loading

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.1016]
Windows Terminal version (if applicable): Version: 1.1.2233.0

Steps to reproduce

Open CMD and start wt maximized/fullscreen and a given profile, e.i. wt -M -p "Command Prompt"

Expected behavior

Windows Terminal opens in maximized mode with the "Command Prompt" profile

Actual behavior

Doesn't start and gives error:
image

Additional information

  • wt -M
    launches the terminal in maximized mode with default profile
  • wt -p "Command Prompt" -d D:/ ; -M
    launches the terminal maximized and the given profile, but with a second tab with the default profile
  • wt -p "Command Prompt" -d D:/ ; -M split-pane -d D:/ -p "Windows PowerShell"
    launches the terminal with 2 tabs with the selected profiles in maximized mode
  • wt -M -p "Command Prompt" -d D:/ ; split-pane -d D:/ -p "Windows PowerShell"
    doesn't work
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Aug 17, 2020
@DHowett
Copy link
Member

DHowett commented Aug 17, 2020

-M and -F are only available in version 1.2+.

@DHowett DHowett closed this as completed Aug 17, 2020
@DHowett DHowett added Issue-Question For questions or discussion Resolution-Answered Related to questions that have been answered and removed Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Aug 17, 2020
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Aug 17, 2020
@Guiorgy
Copy link
Author

Guiorgy commented Aug 17, 2020 •
edited
Loading

@DHowett
The docs didn't mention a version restriction. But more importantly, as I mentioned at the end of my post, wt -M as well as wt -p "profile 1" ; -M split-pane -p "profile 2" do work with my version of the terminal, so saying that -M/-F are only available in 1.2 can't be right?

@DHowett
Copy link
Member

DHowett commented Aug 17, 2020

Whoops, you're totally right. This is an unusual interaction between the "default" command (new-tab) and arguments that belong to wt.

Right now, wt is treated like wt new-tab. Unfortunately, this means that wt -M is treated like wt new-tab -M, which definitely isn't valid. -M is an argument for the global context (and can only be specified before a command).

Workaround:

wt -M new-tab -p "Command prompt"

That also explains why your -M split-pane example works.

Sorry about that!

/cc @zadjii-msft

@DHowett DHowett reopened this Aug 17, 2020
@DHowett DHowett added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. and removed Resolution-Answered Related to questions that have been answered Issue-Question For questions or discussion labels Aug 17, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Aug 17, 2020
@DHowett DHowett added the Priority-2 A description (P2) label Aug 17, 2020
@DHowett DHowett added this to the Terminal Backlog milestone Aug 17, 2020
@Guiorgy Guiorgy closed this as completed Aug 18, 2020
@Guiorgy Guiorgy reopened this Aug 18, 2020
@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Aug 18, 2020
@zadjii-msft zadjii-msft mentioned this issue Aug 18, 2020
Open
40 tasks
@DHowett DHowett mentioned this issue Sep 16, 2020
Closed
@Don-Vito Don-Vito mentioned this issue Nov 18, 2020
Merged
3 tasks
@ghost ghost added the In-PR This issue has a related PR label Nov 18, 2020
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Nov 18, 2020
DHowett pushed a commit that referenced this issue Nov 18, 2020
@Don-Vito
Fix combining wt args and "wt new-tab" args in implicit context (#8315)
435e457 
Currently when implicit tab command is specified (i.e., we have
parameters for new-tab, but don't have the explicit subcommand name) we
fallback to parsing the entire arg list as new tab command.

However, if we also have a launch profile (or anything else that might in
the future belong to the upper scope) it is passed as a parameter to the
new tab command, failing the parsing.

The idea behind my solution is to run the parser as a prefix command -
i.e., as long as we succeed to parse [options] / [subcommand] we will
parse them (populating the fields like a launch mode), but once we will
discover something unfamiliar, like profile, we will know that the
prefix is over and will handle the remaining suffix as a new tab
command.

## Validation Steps Performed
* UT added
* Manual run of different options

Closes #7318
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Nov 18, 2020
@DHowett DHowett mentioned this issue Dec 4, 2020
Closed
DHowett pushed a commit that referenced this issue Jan 25, 2021
@Don-Vito @DHowett
Fix combining wt args and "wt new-tab" args in implicit context (#8315)
817df81 
Currently when implicit tab command is specified (i.e., we have
parameters for new-tab, but don't have the explicit subcommand name) we
fallback to parsing the entire arg list as new tab command.

However, if we also have a launch profile (or anything else that might in
the future belong to the upper scope) it is passed as a parameter to the
new tab command, failing the parsing.

The idea behind my solution is to run the parser as a prefix command -
i.e., as long as we succeed to parse [options] / [subcommand] we will
parse them (populating the fields like a launch mode), but once we will
discover something unfamiliar, like profile, we will know that the
prefix is over and will handle the remaining suffix as a new tab
command.

## Validation Steps Performed
* UT added
* Manual run of different options

Closes #7318

(cherry picked from commit 435e457)
@ghost
Copy link

ghost commented Jan 28, 2021

🎉This issue was addressed in #8315, which has now been successfully released as Windows Terminal v1.5.10271.0.:tada:

Handy links:

@ghost
Copy link

ghost commented Jan 28, 2021

🎉This issue was addressed in #8315, which has now been successfully released as Windows Terminal Preview v1.6.10272.0.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal Backlog
Development

Successfully merging a pull request may close this issue.

Fix combining wt args and "wt new-tab" args in implicit context Don-Vito/terminal
3 participants
@DHowett @zadjii-msft @Guiorgy