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.

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

Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.) #607

Closed
fcharlie opened this issue May 9, 2019 · 32 comments · Fixed by #4023
Closed
Assignees
Labels
Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@fcharlie
Copy link
Contributor

fcharlie commented May 9, 2019

When Windows Terminal is installed on Windows 10, according to UWP package setting: https://github.com/microsoft/Terminal/blob/e37ba7a923427c9a874a6d5bdc27c80fe59db83c/src/cascadia/CascadiaPackage/Package.appxmanifest#L51
A ReparsePoint of type IO_REPARSE_TAG_APPEXECLINK is created in path %LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe to start Windows Terminal. This is great, however, wt.exe should support richer command line arguments to enable third-party applications to open specific terminals.

@DHowett-MSFT
Copy link
Contributor

It absolutely should. I'll mark this and use it as the backlog entry for supporting things like:

--profile
--command
--connection
--workdir (or whatever)

This'll help out with shortcut pinning, and let you do things like "I want to temporary launch WSL with my Powershell profile/keybindings (wt --profile Powershell -c wsl.exe)

@DHowett-MSFT DHowett-MSFT added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label May 9, 2019
@DHowett-MSFT DHowett-MSFT changed the title Feature request: Wt.exe better command line support Feature: wt.exe supports command line arguments (profile, command, directory, etc.) May 9, 2019
@DHowett-MSFT DHowett-MSFT changed the title Feature: wt.exe supports command line arguments (profile, command, directory, etc.) Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.) May 9, 2019
@fcharlie
Copy link
Contributor Author

fcharlie commented May 9, 2019

@DHowett-MSFT Very Good. you can use CommandLineToArgvW convert Commandline to Argv.
If you need to parse Argv, the ParseArgv I wrote may be useful :https://github.com/M2Team/Privexec/blob/master/include/parseargv.hpp

ParseArgv support subcommand

// https://github.com/M2Team/Privexec/blob/master/wsudo/wsudo.cc
// ParseArgv todo
int AppMode::ParseArgv(int argc, wchar_t **argv) {
  av::ParseArgv pa(argc, argv, true);
  pa.Add(L"version", av::no_argument, L'v')
      .Add(L"help", av::no_argument, L'h')
      .Add(L"user", av::required_argument, L'u')
      .Add(L"new-console", av::no_argument, L'n')
      .Add(L"hide", av::no_argument, L'H')
      .Add(L"wait", av::no_argument, L'w')
      .Add(L"verbose", av::no_argument, L'V')
      .Add(L"appx", av::required_argument, L'x')
      .Add(L"cwd", av::required_argument, L'c')
      .Add(L"env", av::required_argument, L'e')
      .Add(L"lpac", av::no_argument, L'L')
      .Add(L"", av::no_argument, L'a')
      .Add(L"", av::no_argument, L'M')
      .Add(L"", av::no_argument, L'U')
      .Add(L"", av::no_argument, L'A')
      .Add(L"", av::no_argument, L'S')
      .Add(L"", av::no_argument, L'T')
      .Add(L"appname", av::required_argument, 1001)
      .Add(L"disable-alias", av::no_argument, 1002);
  av::error_code ec;
  auto result = pa.Execute(
      [&](int val, const wchar_t *va, const wchar_t *) {
        switch (val) {
        case 'v':
          Version();
          exit(0);
        case 'h':
          Usage();
          exit(0);
        case 'u':
          if (!IsAppLevel(va, level)) {
            priv::Print(priv::fc::Red, L"wsudo unsupport user level: %s\n", va);
            return false;
          }
          break;
        case 'n':
          visible = priv::VisibleNewConsole;
          break;
        case 'H':
          visible = priv::VisibleHide;
          break;
        case 'w':
          wait = true;
          break;
        case 'V':
          verbose = true;
          break;
        case 'x':
          appx = va;
          break;
        case 'c':
          cwd = va;
          break;
        case 'e':
          envctx.Append(va);
          break;
        case 'L':
          lpac = true;
          break;
        case 'a':
          level = priv::ProcessAppContainer;
          break;
        case 'M':
          level = priv::ProcessMandatoryIntegrityControl;
          break;
        case 'U':
          level = priv::ProcessNoElevated;
          break;
        case 'A':
          level = priv::ProcessElevated;
          break;
        case 'S':
          level = priv::ProcessSystem;
          break;
        case 'T':
          level = priv::ProcessTrustedInstaller;
          break;
        case 1001:
          appname = va;
          break;
        case 1002:
          disablealias = true;
          break;
        default:
          break;
        }
        return true;
      },
      ec);
  if (!result) {
    priv::Print(priv::fc::Red, L"wsudo ParseArgv: %s\n", ec.message);
    return 1;
  }
  /// Copy TO
  args = pa.UnresolvedArgs();
  return 0;
}

@DHowett-MSFT
Copy link
Contributor

Hey, that's pretty helpful.
Thanks!

@fcharlie
Copy link
Contributor Author

fcharlie commented May 9, 2019

@DHowett-MSFT
I created a commit and I don't know if such a change meets the requirements of the Windows Terminal team. see: https://github.com/fcharlie/Terminal/commit/e4cc84f1db77e7f268bbfc9dea9703ea3a5877a1

@zadjii-msft zadjii-msft added this to the Windows Terminal v1.0 milestone May 9, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Product-Terminal The new Windows Terminal. and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@Dabraleli
Copy link

Dabraleli commented May 21, 2019

I'm not sure if I should create new issue so I'll write my idea here.
What about additional option to select which way this request will be treated?
By this I mean, option to select should this command be executed in new window or in new tab.
Is it possible to implement same behavoir just like almost any multifile editor to execute command (similar to file) in separate tab, not window, if window already exists?

@isaacrlevin
Copy link

Just curious on status of this? Maybe a WIP PR?

@DHowett-MSFT
Copy link
Contributor

The status of this issue appears to be “Spec Needed”, “Open”, “Issue-Feature” (it is a big enough request that it needs a specification). If there’s a WIP pull request, I am not seeing it mentioned.

@jessehouwing
Copy link

It would be nice when the --workdir option would default to the current working directory of the calling process. That way one can open wt from the explorer bar:

image

And from other tools such as "Open here" and 3rd part tools like the Tower Git Client.

ghost pushed a commit that referenced this issue Dec 9, 2019
…errides (#3825)

## Summary of the Pull Request


This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added:
* `profile`
* `commandline`
* `tabTitle`
* `startingDirectory`

`profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default.

`commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607.

With this PR, you can make bindings like the following:

```json

{ "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } },
{ "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } },
{ "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } },
{ "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } },
{ "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } },
{ "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } },
{ "keys": ["ctrl+g"], "command": { "action": "newTab" } },
{ "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } },
{ "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } },
{ "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } }
```

## References

This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments.

## PR Checklist
* [x] Closes #998
* [x] I work here
* [x] Tests added/passed
* [x] Requires documentation to be updated

## Validation Steps Performed
There are tests 🎉

Manually added some bindings, they opened the correct profiles in panes/tabs
@ghost ghost added the In-PR This issue has a related PR label Dec 19, 2019
@ParadoxGBB
Copy link

Part of this being able to launch WT via external processes/shortcuts should also make a constant way to reference and include the WT icon in shortcuts. I might have missed the best way to do it, but so far the only way I was able to get this working is to manually convert a file from C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.7.3451.0_x64__8wekyb3d8bbwe\Images and include it in my app myself, which I imagine would encourage fragmentation and not a good thing.

@b1tninja
Copy link

In regards to the icon, there is likely no good way to do that. A wt launcher / profile editor maybe... In theory images could be loaded dynamically from a dll, but I imagine that becomes more trouble than it would be worth. When distributions are registered it would be kind of nice to have a shortcut of some sort created imo

@daveola
Copy link

daveola commented Jan 15, 2020

The proposed ability to select profiles on the command line doesn't seem to be available yet (at least as of 2020/01) so I've hacked together a solution that let's you specify profile (and currently also the window size) using the current Windows Terminal found in the app store (or via github).

See:

http://davesource.com/Solutions/20200114.Windows-Terminal-command-line-options/
It wouldn't be too hard to add the ability to control other options from the command line as well.

@zadjii-msft
Copy link
Member

@daveola For the record, this is in a PR currently over in #4023. It's actually nearly complete as well (*cough* @DHowett-MSFT)

zadjii-msft added a commit that referenced this issue Jan 15, 2020
## Summary of the Pull Request

This is the spec for adding commandline arguments to the Windows Terminal. This includes design work for a powerful future version of the commandline args for the Terminal, as well as a way that system could be implemented during 1.0 to provide basic functionality, while creating commandlines that will work without modification in (a future Windows Terminal version).   

## References

Referenced in the course of this spec:

* #607  Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.) 
* #1060 Add "open Windows terminal here" into right-click context menu 
* #576  Feature Request: Task Bar jumplist should show items from profile 
* #1357 Draft spec for adding profiles to the Windows jumplist 
* #2080 Spec for tab tear off and default app 
* #632  [Question] Configuring Windows Terminal profile to always launch elevated 
* #2068 New window key binding not working 

## PR Checklist
* [x] Specs #607
* [x] I work here
* [x] _it's a spec_

## Detailed Description of the Pull Request / Additional comments

Read the spec.

-----------------------------------------------------
* Let's commit this bewfore I go hog-wild on new-window

* new-window vs new-tab discussion

* Well, this is ready for a review

* -P -> -% for --percent

* Big note on powershell

  of course, powershell has to use `;` as the command seperator

* Minor typos

* This is a lot of feedback from PR

  bigly, it's focus-pane and focus-tab

* Add notes on implementation, based on investigation

* Apply suggestions from @miniksa

* some updates after actually implementing the thing

* some minor things from PR

* Apply suggestions from code review

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>

* comments from dustin's latest review

* more comments from dustin

* mostly just typos

Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
@daveola
Copy link

daveola commented Jan 15, 2020

Almost complete doesn't open a terminal on my computer.. :)

@ghost ghost closed this as completed in #4023 Jan 27, 2020
ghost pushed a commit that referenced this issue Jan 27, 2020
## Summary of the Pull Request

Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495

## References

* Original issue: #607
* Original spec: #3495

## PR Checklist
* [x] Closes #607
* [x] I work here
* [x] Tests added/passed
* [ ] We should probably add some docs on these commands
* [x] The spec (#3495) needs to be merged first!

## Detailed Description of the Pull Request / Additional comments

🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now.

This PR adds support for three initial sub-commands to the `wt.exe` application:
* `new-tab`: Used to create a new tab.
* `split-pane`: Used to create a new split.
* `focus-tab`: Moves focus to another tab.

These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands

Important scenarios added:
* `wt -d .`: Open a new wt instance in the current working directory #878
* `wt -p <profile name>`: Create a wt instance running the given profile, to unblock  #576, #1357, #2339
* `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 

## Validation Steps Performed

* Ran tests
* Played with it a bunch
@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 Jan 27, 2020
@ghost
Copy link

ghost commented Feb 13, 2020

🎉This issue was addressed in #4023, which has now been successfully released as Windows Terminal Preview v0.9.433.0.:tada:

Handy links:

marjimgu added a commit to marjimgu/terminal that referenced this issue Mar 29, 2020
The index.md is outdate indicating there is not commandline options but since versio XXXX there. And some are docummented in UsingCommandlineArguments.md. 

I also added reference to list to changes of the WT releases.

I removed the line. "None at this time. See issue [microsoft#607](microsoft#607)"
@XeonG

This comment has been minimized.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. 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
Development

Successfully merging a pull request may close this issue.