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

Unclear how to determine installed version? #5494

Closed
tiesmaster opened this issue Apr 23, 2020 · 9 comments · Fixed by #5501
Closed

Unclear how to determine installed version? #5494

tiesmaster opened this issue Apr 23, 2020 · 9 comments · Fixed by #5501
Assignees
Labels
Area-Commandline wt.exe's commandline arguments Issue-Task It's a feature request, but it doesn't really need a major design. 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

@tiesmaster
Copy link

tiesmaster commented Apr 23, 2020

For me, it's unclear how to determine what my currently installed version of the Windows Terminal is. I tried the following things:

Check the command-line arguments: but it's not listed, and "probing" for --version gives an error that it's not an argument that's expected.

Check the Windows Store (I installed it through that), but I don't see a version anywhere. I don't really use the Windows Store, so maybe I overlooked it, but these are the places I checked:

  • the detailed listing
  • My Library > Installed: it states when modified, but not the version
  • My Library > Installed: same as above
  • My Library > Downloads: it states versions, but not the Windows Terminal is not listed under Recent Activity, but Available Updates, and that doesn't list a version (see Context below)

Looked for an issue about this in this repo, but couldn't find anything related: almost any issue has the word version in it, since it's asked when creating an issue 😅

Checked the issue templates, although there is listed how to find the version of Windows, not of the Windows Terminal

The properties pane on the wt.exe executables I could find, but they're completely empty, as the files are also 0 bytes. I checked these locations:

  • C:\Users\ties\AppData\Local\Microsoft\WindowsApps\wt.exe
  • C:\Users\ties\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe

Context

I was looking into an issue I keep running into (#3609), and noticed I was running an older version of the Windows Terminal. Before I was going to update it, I wanted to known which version I have installed, so I can cross check all the related issues, and comments, if I can expect it to be fixed.

Suggested Improvements

  • Add to the issue templates
  • Add to the main docs somewhere
  • Add support for --version argument to wt.exe
@tiesmaster tiesmaster added the Issue-Docs It's a documentation issue that really should be on MicrosoftDocs/Console-Docs label Apr 23, 2020
@ghost ghost added 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 Apr 23, 2020
@WSLUser
Copy link
Contributor

WSLUser commented Apr 23, 2020

Go to the About Page. If you don't have it then you're running an extremely early build of Windows Terminal and should update to the latest release. However I do agree we need to add --version to check via CLI (verified this still doesn't work on the latest .11 release)

@ghost ghost added the In-PR This issue has a related PR label Apr 23, 2020
@tiesmaster
Copy link
Author

👍 I was looking for something like the about page, but couldn't find it, completely overlooked the drop-down arrow.

Cool that the --version is being picked up ;) Thnx for the comment in #4632.

@zadjii-msft zadjii-msft added Area-Commandline wt.exe's commandline arguments Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. and removed Issue-Docs It's a documentation issue that really should be on MicrosoftDocs/Console-Docs labels Apr 24, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Apr 24, 2020
@zadjii-msft zadjii-msft self-assigned this Apr 24, 2020
@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.1 milestone Apr 25, 2020
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Apr 25, 2020
@ghost ghost closed this as completed in #5501 May 4, 2020
@ghost ghost removed the In-PR This issue has a related PR label May 4, 2020
ghost pushed a commit that referenced this issue May 4, 2020
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label May 4, 2020
@ghost
Copy link

ghost commented Jun 18, 2020

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

Handy links:

@dschulman-repay
Copy link

As of 1.11.3471.0, this still doesn't work the way I'd hoped it would. While wt -v does produce the desired information (in a warning dialog for some reason), I wanted a way to get it programmatically à la python -V without having to resort to parsing it out of something like REG QUERY "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\Microsoft.WindowsTerminal_8wekyb3d8bbwe\Schemas" /v PackageFullName or REG QUERY "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve or REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve.

Is there a way to do this? If not, would it be possible to add a different command-line flag to the wt executable with this behavior?

If there are no plans to add such functionality, I could always put together a PowerShell function like

function Get-WindowsTerminalVersion {
    $WindowsTerminalVersionRegistryHive = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe"
    $pattern = "_(.*?)_"
    $script:WindowsTerminalVersion = [regex]::match($WindowsTerminalVersionRegistryHive.Path, $pattern).Groups[1].Value
}

but that's pretty ugly and I'd rather not use it.

@DHowett
Copy link
Member

DHowett commented Dec 15, 2021

I'd hoped it would

Hey @dschulman-repay! I'm not sure your use case was captured in this issue (it looks like the original reporter wanted to see if they had a fixed vs. broken version of Terminal), so I'm not too surprised that this resolution didn't help you out. We're looking at offering this info in the environment in #1040; however, if that's not enough, I'd love to hear about your scenario!

In general, we encourage folks not to detect the Terminal version and make any application decisions based on it, because many of the underlying components that make up the Terminal are also part of the Windows Console. Behavioral decisions made based on the Terminal version will exclude folks who are using a new-enough console outside of Terminal, or using Visual Studio Code or the Visual Studio IDE's integrated terminal or even ConEmu on newer versions of Windows.

for some reason

It is a very sad reason ("displaying output in a dialog" section).

@dschulman-repay
Copy link

dschulman-repay commented Dec 15, 2021

While I can understand the rationale for not encouraging users to use the version of Terminal as a basis for application decisions, my use case is literally an inventory script of the sort that an admin might run remotely to see who's got what (and possibly push new versions of dangerously out-of-date applications as needed). At the moment, what I'm collecting looks like this:

Hardware
        Machine                                 Dell Inc. Precision 5550 (<machine ID>)
        CPU                                     Intel® Core™ i7-10875H CPU @ 2.30 GHz
        TPM                                     Enabled, Activated, Ready, Version 2.0
        Temperature                             60.1 °C / 140.2 °F (critical temperature 100.1 °C / 212.2 °F)
        BIOS version                            1.10.0 (2021-09-27)
        Product                                 0GX59H
        Baseboard                               /GGGL6D3/CNCMK0014I0544/
        Dell Service Tag                        GGGL6D3
        Express Service Code                    35870638571
        RAM                                     32 GB
        Video resolution and color depth        1920 × 1200 × 32
Battery
        Chemistry                               Unknown
        Capacity                                84290 mAh
        Status                                  On AC power
        Operational Status                      OK
        Manufactured                            2021-03-25
        Availability                            unknown
        Remaining charge                        100%
Disks
        Drive   Volume          Filesystem      Free space

        C:      OS              NTFS            263.60 GB free / 474.86 GB:     55.51%
Windows
        64-bit Windows 10 Enterprise version    2009
        OS build                                19043.1348 (Windows version 21H1, May 2021 Update)
        Windows product key                     D11RC-NTROL-VUSAW-BBUI6-NRT0E
        Installed .NET Framework version        4.8 (Windows 10 May 2020 Update)
        Installed .NET SDK version              6.0.101
        Installed .NET runtime version          6.0.1
        Windows Terminal                        1.11.3471.0
        PowerShell                              Core 7.2.1
        WSL
                 Ubuntu-20.04 (Running)         WSL 2 DEFAULT
                 docker-desktop-data (Running)  WSL 2
                 docker-desktop (Running)       WSL 2
Package management
        Chocolatey                              0.11.3
        WinGet                                  1.1.13405
OpenSSL                                         3.0.1
cURL                                            7.80.0
Visual Studio Code                              1.63.1
Python
        Installed version:                      3.10.1
Java
        OpenJDK 17.0.1                          17.0.1.0
        Java™ SE 8                              8.0.3110.11
        OpenJDK 17.0.1                          17.0.1.0
Network
        Domain (primary DNS suffix)             WORKGROUP
        Network adapter                         Ethernet 3
        Network type                            Realtek USB GbE Family Controller #3
        Link speed                              1 Gbps
        Connected to Internet?                  True
        VPN status                              Connected on Local Area Connection
        Ping round-trip time                    17 ms
        Estimated connection speed              58.63 Mbps
        Network SSID                            Network Local Area Connection 2
        Connection-specific DNS suffix          nc.rr.com
        IPv4 address                            192.168.1.105
        IPv6 address                            fe80::2cab:2a1f:39a1:a5eb%19
        Physical address                        48:51:C5:07:9D:EB
Admin
        Registered to                           Admin (Me Want Cookie)
        Userid                                  devnull (Me)
        System installed                        2021-05-16 12:05:27 EDT-04:00
        Last system boot                        2021-12-15 20:09:42 EST-05:00
        Current timestamp                       2021-12-16 14:31:04 EST-05:00

@WSLUser
Copy link
Contributor

WSLUser commented Dec 15, 2021

I noticed package management in your script. This is the route for your use case. There are many ways to determine a release is out for both Chocolately and eventually WinGet once they support updates. One method could be by git commit. You know what it is for each release, so it's reliable (unless Github is down).

@dschulman-repay
Copy link

A lot of the applications I'm tracking have no (public) Chocolatey packages and aren't set up for Windows Package Manager (nor are they registered with Ninite or Scoop), either. Is there no alternative but to set up private Github repos for all of them?

@zadjii-msft
Copy link
Member

Is there another process that's running at 100% CPU? if so, that sounds a bit like #11916.

Regardless, I'd probably open a new thread for that issue, since that seems totally unrelated to determining the installed Terminal version.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Commandline wt.exe's commandline arguments Issue-Task It's a feature request, but it doesn't really need a major design. 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.

6 participants