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 · 31 comments · Fixed by #4023
Closed

Comments

@fcharlie
Copy link
Contributor

@fcharlie 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

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented May 9, 2019

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 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

This comment has been minimized.

Copy link
Contributor Author

@fcharlie 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

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented May 9, 2019

Hey, that's pretty helpful.
Thanks!

@fcharlie

This comment has been minimized.

Copy link
Contributor Author

@fcharlie 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: fcharlie@e4cc84f

@Dabraleli

This comment has been minimized.

Copy link

@Dabraleli 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

This comment has been minimized.

Copy link
Member

@isaacrlevin isaacrlevin commented Jun 22, 2019

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

@DHowett-MSFT

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented Jun 22, 2019

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

This comment has been minimized.

Copy link

@jessehouwing jessehouwing commented Aug 3, 2019

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.

@zadjii-msft zadjii-msft mentioned this issue Nov 26, 2019
2 of 4 tasks complete
zadjii-msft added a commit that referenced this issue Nov 27, 2019
## Summary of the Pull Request

Moves all the code responsible for dispatching an `ActionAndArgs` to it's own class, `ShortcutActionDispatch`. Now, the `AppKeyBindings` just uses the single instance of a `ShortcutActionDispatch` that the `TerminalPage` owns to dispatch events, without the need to re-attach the event handlers every time we reload the settings.

## References

This is something I originally did as a part of #2046.

I need this now for #607.

It's also a part of work for #3475

## PR Checklist
* [x] This is a bullet point within #3475
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

With this change, we'll be able to have other things dispatch `ShortcutAction`s easily, by constructing an `ActionAndArgs` and just passing it straight to the `ShortcutActionDispatch`.

## Validation Steps Performed

Ran the Terminal, tried out some keybindings, namely <kbd>Ctrl+c</kbd> for copy when there is a selection, or send `^C` when there isn't. That still works. 

Reloading settings also still works. 

-----------------------------------------------
* Move action handling to it's own class separate from AKB. This is the first checkbox in #3475

(cherry picked from commit 696726b)

* clean up doc comments
@henriksen

This comment has been minimized.

Copy link

@henriksen henriksen commented Nov 28, 2019

Now that we have the option to split windows and it's almost Christmas, I'd like to have that option from the command line as well.

I would like to be able to run a shortcut that (in order of priority)

  1. Opens up a terminal window
  2. Splits it according to what I specified on the command line (for instance, first horizontally, and then the bottom one vertically)
  3. Specify which path each split should start in
  4. Specify a command each split should run
  5. Set the size and position of the window
  6. Specify what shell to run in each split
@zadjii-msft

This comment has been minimized.

Copy link
Member

@zadjii-msft zadjii-msft commented Nov 28, 2019

@henriksen If that's what you want, then I have a PR that will make you very happy: #3495

zadjii-msft added a commit that referenced this issue Nov 28, 2019
## Summary of the Pull Request

We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. 

Currently, there's one argument: "style", which is one of "vertical" or "horizontal."

## References
This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first)

This will probably conflict with #3658
## PR Checklist
* [ ] Doesn't actually close anything, only enables #998
* [x] I work here
* [ ] Tests added/passed - yea okay no excuses here
* [x] Requires documentation to be updated

## Validation Steps Performed
Added new keybindings with the args - works
Tried the old keybindings without the args - still works
---------------------------------------
* Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally

* Update documentation too

* Good lord this is important

* Add a test too, though I have no idea if it works

* "style" -> "split"

* pr comments from carlos
@henriksen

This comment has been minimized.

Copy link

@henriksen henriksen commented Nov 29, 2019

@zadjii-msft Well, I guess Christmas came early this year! Looks like the spec has everything I wanted! 👍

msftbot bot added 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
@msftbot msftbot bot added the In-PR label Dec 19, 2019
@ParadoxGBB

This comment has been minimized.

Copy link

@ParadoxGBB ParadoxGBB commented Jan 10, 2020

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

This comment has been minimized.

Copy link

@b1tninja b1tninja commented Jan 14, 2020

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

This comment has been minimized.

Copy link

@daveola 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

This comment has been minimized.

Copy link
Member

@zadjii-msft zadjii-msft commented Jan 15, 2020

@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>
@zadjii-msft zadjii-msft moved this from Spec In Review ⏰ to Spec Accepted! 🎉 in Specification Tracker Jan 15, 2020
@daveola

This comment has been minimized.

Copy link

@daveola daveola commented Jan 15, 2020

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

@msftbot msftbot bot closed this in #4023 Jan 27, 2020
msftbot bot added 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
@msftbot msftbot bot added Resolution-Fix-Committed and removed In-PR labels Jan 27, 2020
@msftbot

This comment has been minimized.

Copy link

@msftbot msftbot bot commented Feb 13, 2020

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

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Specification Tracker
  
Spec Accepted! 🎉
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.