2020-01-14:
Windows Terminal - hack to add command-line options!
Problem
I have to use Windows sometimes. That's the problem in a nutshell.
Regardless, to alleviate this, I use Windows Terminal and WSL (Windows Subsystem for Linux)
so I can do things like use the Terminal window for:
- Ubuntu bash
- Powershell & cmd
- ssh logins to a variety of machines
I want to be able to use hotkeys start up the windows terminal
with different setups.
But of course Windows Terminal takes (as of 2020/01) exactly ZERO command line options.
So I forced it.
Requirements
My solution uses a script written in the ruby language, because ruby is beautiful and simple.
But that means you probably need WSL with Ubuntu for Windows installed
(and then a quick 'sudo apt install ruby' to get ruby), or at least
a ruby version for Windows installed, and then you need to fix all
the paths.
Failing that, someone well versed in cmd or Powershell could probably
write a replacement solution that works without ruby. Be my guest.
Here's the ruby script you need, I have it installed in my WSL path at '~/bin/term':
DOWNLOAD
(right-click and "save-as" and then copy it to your WSL installation)
Once it's in your WSL path, use an Ubuntu/bash shell to make sure it's executable: (use whatever path is the final location)
chmod +rx ~/bin/term
Solution
First of all we have to know how to call Windows Terminal from
the command line. The easiest way I have found is:
%LocalAppData%\Microsoft\WindowsApps\wt.exe
If you're calling from something like AutoHotKey, you probably need:
explorer.exe %LocalAppData%\Microsoft\WindowsApps\wt.exe
Unfortunately, at least to date, the wt.exe doesn't parse any command-line options.
Instead, it reads a JSON file that has all the settings (which you can view by clicking
the drop-down arrow on the top bar and choosing "Settings"). The settings live
in a location such as:
%LocalAppDataUnix%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\profiles.json
or (from your home directory):
%USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\profiles.json
The settings file can take a number of options, and can also specify multiple named profiles, but
only one is the default.
So my ruby script reads the settings, temporarily updates the default (as well as the size of
the window), writes it out, launches the terminal, and then restores the settings to their
original value.
Now we call the script from Windows (instead of launching the terminal directly) and
that's where I use WSL/Ubuntu, which has a bash.exe that you can use to run scripts like this:
"%windir%\System32\bash.exe" -c "~/bin/term some_profile_name_here"
Where '~/bin/term' is the install location for the ruby script.
This means you can do things like: (assuming you have profiles "machine1" "machine2",...)
"%windir%\System32\bash.exe" -c "~/bin/term machine1 -geometry 100x40"
"%windir%\System32\bash.exe" -c "~/bin/term machine2 -geometry 150x75"
"%windir%\System32\bash.exe" -c "~/bin/term -list"
The last command will list all the profiles it has found in the terminal settings.
This does mean that we can currently only start connections that have a profile, and we can only
currently change the window size, but it would be easy for anyone with some programming ability
to add more options for any options that are found in the terminal settings.
Caveats
If you have profile names with spaces in them, you will have to quote them
appropriately, or else it might just be easier to take the spaces out.
Because we are using this hack of editing the terminal settings, launching and then
restoring it means we have a bit of a race condition. If we try to launch too many
at the same time, then we will get unexpected behavior.
Furthermore, there is a built-in delay between launching terminal and restoring
the settings, because we don't know at what point the terminal app has finally
finished reading the settings file. If you have a slower system and find that it's
sometimes opening the default profile instead of the one you requested, you might
want to increase the delay inside the script (though that will increase the amount
of time you need to leave between calling the script multiple times)
Hope that's useful to people!
Back to Solutions.
