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

@fcharlie commented on GitHub (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;
}

@fcharlie commented on GitHub (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](https://github.com/M2Team/Privexec/blob/master/include/parseargv.hpp) ParseArgv support `subcommand` ```c++ // 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; } ``` ![](https://github.com/M2Team/Privexec/raw/master/docs/images/wsudo.png)

claunia commented

@DHowett-MSFT commented on GitHub (May 9, 2019):

Hey, that's pretty helpful.
Thanks!

@DHowett-MSFT commented on GitHub (May 9, 2019): Hey, that's pretty helpful. Thanks!

claunia commented

@fcharlie commented on GitHub (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: e4cc84f1db

@fcharlie commented on GitHub (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

claunia commented

@Dabraleli commented on GitHub (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?

@Dabraleli commented on GitHub (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?

claunia commented

@isaacrlevin commented on GitHub (Jun 22, 2019):

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

@isaacrlevin commented on GitHub (Jun 22, 2019): Just curious on status of this? Maybe a WIP PR?

claunia commented

@DHowett-MSFT commented on GitHub (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.

@DHowett-MSFT commented on GitHub (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.

claunia commented

@jessehouwing commented on GitHub (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:

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

@jessehouwing commented on GitHub (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](https://user-images.githubusercontent.com/4173387/62415926-3e382e00-b632-11e9-860b-634987786ce8.png) And from other tools such as "Open here" and 3rd part tools like the Tower Git Client.

claunia commented

@Jckf commented on GitHub (Aug 20, 2019):

Just commenting to show my support for this. It would be super nice if this made it possible to open a new Terminal window with a pre-defined set of tabs.

Some applications take argument order into consideration, i.e. example.exe --one-arg --two-arg is not the same as example.exe --two-arg --one-arg. Implementing something like this would make it possible to start multiple tabs with different configuration in a single command, by repeating arguments in different contexts.

Example: wt.exe --command cmd.exe --workdir d:\Projects\API --title API --command cmd.exe --workdir d:\Projects\UI --title UI

@Jckf commented on GitHub (Aug 20, 2019): Just commenting to show my support for this. It would be super nice if this made it possible to open a new Terminal window with a pre-defined set of tabs. Some applications take argument order into consideration, i.e. `example.exe --one-arg --two-arg` is not the same as `example.exe --two-arg --one-arg`. Implementing something like this would make it possible to start multiple tabs with different configuration in a single command, by repeating arguments in different contexts. Example: `wt.exe --command cmd.exe --workdir d:\Projects\API --title API --command cmd.exe --workdir d:\Projects\UI --title UI`

claunia commented

@fcharlie commented on GitHub (Aug 21, 2019):

In fact, I would recommend the same command-line style as wsudo mentioned above (similar to the conhost command line). After parsing the parameters that wt can handle, the rest are shells (cmd/pwsh/bash .. .) parameters.

wt.exe --workdir d:\some\dir --title "some title" cmd.exe /c /path/to/some.bat

@fcharlie commented on GitHub (Aug 21, 2019): In fact, I would recommend the same command-line style as wsudo mentioned above (similar to the conhost command line). After parsing the parameters that wt can handle, the rest are shells (cmd/pwsh/bash .. .) parameters. ```shell wt.exe --workdir d:\some\dir --title "some title" cmd.exe /c /path/to/some.bat ```

claunia commented

@fcharlie commented on GitHub (Aug 24, 2019):

I have more ideas about the wt support command line, for reference only:

Through experimentation, I found that starting the wt from the command line and starting the Windows terminal from the start menu is different. This is a prerequisite for wt to support more command lines.

Start wt from cmd:

Run Windows Termianl from Start:

View the CreateProcessW statement:

BOOL WINAPI CreateProcessW(
  LPCWSTR               lpApplicationName,
  LPWSTR                lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL                  bInheritHandles,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCWSTR               lpCurrentDirectory,
  LPSTARTUPINFOW        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

We can almost speculate that Windows sets lpApplicationName to the full path of Windows Terminal when starting wt, and sets lpCommandLine to the command line. In wsudo(wsudo-tie), I did the same.

Having said that, we can use GetCommandLine and CommandLineToArgv to split the commandline. If Argv0 is wt(wt.exe/wtd/wtd.exe), we can be sure that this is the terminal started from wt, so we start parsing the parameters. Replace the workdir title connection with a specific configuration item (or the first profile if no profile is specified). If --workdir is not specified then the current directory of wt is used.

Also I don't recommend --command to set the command line, which may cause the caller to need double escaping.

@fcharlie commented on GitHub (Aug 24, 2019): I have more ideas about the wt support command line, for reference only: Through experimentation, I found that starting the wt from the command line and starting the Windows terminal from the start menu is different. This is a prerequisite for wt to support more command lines. Start wt from cmd: ![屏幕截图(11)](https://user-images.githubusercontent.com/6904176/63630132-33c5ee80-c64a-11e9-8ee7-5d996fa62d2b.png) Run Windows Termianl from Start: ![屏幕截图(12)](https://user-images.githubusercontent.com/6904176/63630136-39233900-c64a-11e9-9ea2-365ead6c8f0e.png) View the [CreateProcessW](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) statement: ```c++ BOOL WINAPI CreateProcessW( LPCWSTR lpApplicationName, LPWSTR lpCommandLine, LPSECURITY_ATTRIBUTES lpProcessAttributes, LPSECURITY_ATTRIBUTES lpThreadAttributes, BOOL bInheritHandles, DWORD dwCreationFlags, LPVOID lpEnvironment, LPCWSTR lpCurrentDirectory, LPSTARTUPINFOW lpStartupInfo, LPPROCESS_INFORMATION lpProcessInformation ); ``` We can almost speculate that Windows sets lpApplicationName to the full path of Windows Terminal when starting wt, and sets lpCommandLine to the command line. In [wsudo(wsudo-tie)](https://github.com/M2Team/Privexec/blob/master/wsudo/wsudo-tie.cc#L208), I did the same. Having said that, we can use GetCommandLine and CommandLineToArgv to split the commandline. If Argv0 is wt(wt.exe/wtd/wtd.exe), we can be sure that this is the terminal started from wt, so we start parsing the parameters. Replace the `workdir` `title` `connection` with a specific configuration item (or the first profile if no profile is specified). If --workdir is not specified then the current directory of wt is used. Also I don't recommend `--command` to set the command line, which may cause the caller to need double escaping.

claunia commented

@AliRafiee commented on GitHub (Sep 20, 2019):

I would also like to suggest the ability to target a specific window of terminal. Say that I have an application that wants to open several CMD windows over time, I can use terminal to open them all in the same window, in different tabs.

@AliRafiee commented on GitHub (Sep 20, 2019): I would also like to suggest the ability to target a specific window of terminal. Say that I have an application that wants to open several CMD windows over time, I can use terminal to open them all in the same window, in different tabs.

claunia commented

@AliRafiee commented on GitHub (Sep 20, 2019):

I would also like to suggest using Protocol Activation to enable command line params when launching Terminal from a UWP application.

Specifying this in the package manifest
<uap:Extension Category="windows.protocol">
<uap:Protocol Name="ms-terminal"/>
</uap:Extension>

And running this: ms-terminal: -profile something -command something
Will result in the wWinMain getting this exact string as a command line argument.
“ms-terminal: -profile something -command something”

@AliRafiee commented on GitHub (Sep 20, 2019): I would also like to suggest using Protocol Activation to enable command line params when launching Terminal from a UWP application. Specifying this in the package manifest <uap:Extension Category="windows.protocol"> <uap:Protocol Name="ms-terminal"/> </uap:Extension> And running this: ms-terminal: -profile something -command something Will result in the wWinMain getting this exact string as a command line argument. “ms-terminal: -profile something -command something”

claunia commented

@b1tninja commented on GitHub (Oct 10, 2019):

Yes, the first thing I wanted to do was create a shortcut to launch a specific profile, and after fumbling around trying things like /? /help --help -h, passing the profile guid I came to the issues looking to see if anyone else wanted more than "default"

@b1tninja commented on GitHub (Oct 10, 2019): Yes, the first thing I wanted to do was create a shortcut to launch a specific profile, and after fumbling around trying things like /? /help --help -h, passing the profile guid I came to the issues looking to see if anyone else wanted more than "default"

claunia commented

@stax76 commented on GitHub (Oct 11, 2019):

Why double dash when powershell uses single dash?

@stax76 commented on GitHub (Oct 11, 2019): Why double dash when powershell uses single dash?

claunia commented

@DHowett-MSFT commented on GitHub (Oct 11, 2019):

there are currently 0 dashes because there is no specification for this feature.
traditionally, on all platforms that aren't windows, all "long" options are -- and all short ones are -. PowerShell may not have made the right choice, but that choice was made more than ten years ago so it's a compatibility concern. Consider WSL:

    --list, -l [Options]
        Lists distributions.

        Options:
            --all
                List all distributions, including distributions that are currently
                being installed or uninstalled.

            --running
                List only distributions that are currently running.

            --quiet, -q
                Only show distribution names.

            --verbose, -v
                Show detailed information about all distributions.

    --set-default, -s <Distro>
        Sets the distribution as the default.

    --set-default-version <Version>
        Changes the default install version for new distributions.

    --set-version <Distro> <Version>
        Changes the version of the specified distribution.

@DHowett-MSFT commented on GitHub (Oct 11, 2019): 1. there are currently 0 dashes _because there is no specification for this feature._ 2. traditionally, on all platforms that aren't windows, all "long" options are `--` and all short ones are `-`. PowerShell may not have made the right choice, but that choice was made more than ten years ago so it's a compatibility concern. Consider WSL: ``` --list, -l [Options] Lists distributions. Options: --all List all distributions, including distributions that are currently being installed or uninstalled. --running List only distributions that are currently running. --quiet, -q Only show distribution names. --verbose, -v Show detailed information about all distributions. --set-default, -s <Distro> Sets the distribution as the default. --set-default-version <Version> Changes the default install version for new distributions. --set-version <Distro> <Version> Changes the version of the specified distribution. ```

claunia commented

@stax76 commented on GitHub (Oct 11, 2019):

I think it's mostly a linux tradition that is not bad but I also like powershell way of using -SetVersion instead of --set-version. Probably It has something to do with the dotnet background of powershell.

@stax76 commented on GitHub (Oct 11, 2019): I think it's mostly a linux tradition that is not bad but I also like powershell way of using -SetVersion instead of --set-version. Probably It has something to do with the dotnet background of powershell.

claunia commented

@jstarks commented on GitHub (Oct 14, 2019):

It's not just a tradition, it's encoded in the getopt family of functions, which are available in libc basically everywhere but Windows.

In Windows we use a version of getopt for wsl's option parsing. It might be useful to do the same (e.g. grab a copy of getopt from musl libc) so that things like -- (to separate options from non-option arguments) work in a predictable fashion.

@jstarks commented on GitHub (Oct 14, 2019): It's not just a tradition, it's encoded in the getopt family of functions, which are available in libc basically everywhere but Windows. In Windows we use a version of getopt for wsl's option parsing. It might be useful to do the same (e.g. grab a copy of getopt from musl libc) so that things like `--` (to separate options from non-option arguments) work in a predictable fashion.

claunia commented

@stax76 commented on GitHub (Oct 15, 2019):

After thinking about this I agree now.

@stax76 commented on GitHub (Oct 15, 2019): After thinking about this I agree now.

claunia commented

@michael-hawker commented on GitHub (Oct 22, 2019):

I didn't even know I could use 'wt' to run Terminal. I was looking for my quick Win+R+cmd+Enter replacement, yay! 🙂

@michael-hawker commented on GitHub (Oct 22, 2019): I didn't even know I could use 'wt' to run Terminal. I was looking for my quick Win+R+cmd+Enter replacement, yay! 🙂

claunia commented

@qqkookie commented on GitHub (Nov 14, 2019):

We need consistent treatment of starting (working) directory.

Window terminal should NOT chdir to %USERPROFILE% if there is no "StartingDirectory" entry in profile.json and no directory option. (like -d directory) And if -d option exist, then StartingDirectory entry should be ignored always.

Currently if no "StartingDirectory" entry in profile.json, and wt is run in cmd.exe or from "run command" menu, it always starts in %USERPROFILE% directory, regardless of current directory of invoking process. This is inconsistent behavior with other Windows command line programs and user expectation. It should start in current directory of cmd.exe it was invoked from or "C: Windows/win32" which is current directory of Window Explorer shell "Run command". This is how cmd.exe works.

The "StartingDirectory" entry in profile.json should be ignored if -d directory option exists, regardless that it has directory arguement or not.

Currently, to implement #1060 (Add "open Windows terminal here" into right-click context menu), the "StartingDirectory" should be always set to ".", which invalidates the purpose of having StartingDirectory entry in profile.json. "wt -d" should do the trick regardless of StartingDirectory.

In summary:
No -d option and no StartingDirectory : use current directory of invoking process.
No -d option but have StartingDirectory : use StartingDirectory
-d option without argument (-d alone) : use use current directory of invoking process., ignoring StartingDirectory, i.e -d will let wt ignore StartingDirectory entry.
-d option with argument (-d directory) : use the directory argument

EDIT:
-d~ option: wt will ignore StartingDirectory and use %USERPROFILE%

@qqkookie commented on GitHub (Nov 14, 2019): We need consistent treatment of starting (working) directory. **Window terminal should NOT chdir to `%USERPROFILE%` if there is no "StartingDirectory" entry in `profile.json` and no directory option.** (like -d *directory*) And if -d option exist, then StartingDirectory entry should be ignored always. Currently if no "StartingDirectory" entry in `profile.json`, and wt is run in cmd.exe or from "run command" menu, it always starts in %USERPROFILE% directory, regardless of current directory of invoking process. This is inconsistent behavior with other Windows command line programs and user expectation. It should start in current directory of cmd.exe it was invoked from or "C: Windows/win32" which is current directory of Window Explorer shell "Run command". This is how `cmd.exe` works. The "StartingDirectory" entry in `profile.json` should be ignored if -d directory option exists, regardless that it has directory arguement or not. Currently, to implement #1060 (Add "open Windows terminal here" into right-click context menu), the "StartingDirectory" should be always set to ".", which invalidates the purpose of having `StartingDirectory` entry in profile.json. "wt -d" should do the trick regardless of StartingDirectory. In summary: No -d option and no StartingDirectory : use **current directory** of invoking process. No -d option but have StartingDirectory : use StartingDirectory -d option without argument (-d alone) : use use **current directory** of invoking process., ignoring StartingDirectory, i.e -d will let wt ignore StartingDirectory entry. -d option with argument (-d *directory*) : use the *directory* argument EDIT: -d~ option: wt will ignore StartingDirectory and use %USERPROFILE%

claunia commented

@DHowett-MSFT commented on GitHub (Nov 14, 2019):

@qqkookie you're looking for #3547

@DHowett-MSFT commented on GitHub (Nov 14, 2019): @qqkookie you're looking for #3547

claunia commented

@henriksen commented on GitHub (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)

Opens up a terminal window
Splits it according to what I specified on the command line (for instance, first horizontally, and then the bottom one vertically)
Specify which path each split should start in
Specify a command each split should run
Set the size and position of the window
Specify what shell to run in each split

@henriksen commented on GitHub (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

claunia commented

@zadjii-msft commented on GitHub (Nov 28, 2019):

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

@zadjii-msft commented on GitHub (Nov 28, 2019): @henriksen If that's what you want, then I have a PR that will make you very happy: #3495

claunia commented

@henriksen commented on GitHub (Nov 29, 2019):

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

@henriksen commented on GitHub (Nov 29, 2019): @zadjii-msft Well, I guess Christmas came early this year! Looks like the spec has everything I wanted! 👍

claunia commented

@ParadoxGBB commented on GitHub (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.

@ParadoxGBB commented on GitHub (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.

claunia commented

@b1tninja commented on GitHub (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

@b1tninja commented on GitHub (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

claunia commented

@daveola commented on GitHub (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.

@daveola commented on GitHub (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/](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.

claunia commented

@zadjii-msft commented on GitHub (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 commented on GitHub (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)

claunia commented

@daveola commented on GitHub (Jan 15, 2020):

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

@daveola commented on GitHub (Jan 15, 2020): Almost complete doesn't open a terminal on my computer.. :)

claunia commented