microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!

Welcome to the Windows Terminal, Console and Command-Line repo

This repository contains the source code for:

• Windows Terminal
• Windows Terminal Preview
• The Windows console host (conhost.exe)
• Components shared between the two projects
• ColorTool
• Sample projects that show how to consume the Windows Console APIs

Related repositories include:

• Windows Terminal Documentation (Repo: Contribute to the docs)
• Console API Documentation
• Cascadia Code Font

Installing and running Windows Terminal

Note

Windows Terminal requires Windows 10 2004 (build 19041) or later

Microsoft Store [Recommended]

Install the Windows Terminal from the Microsoft Store. This allows you to always be on the latest version when we release new builds with automatic upgrades.

This is our preferred method.

Other install methods

Via GitHub

For users who are unable to install Windows Terminal from the Microsoft Store, released builds can be manually downloaded from this repository's Releases page.

Download the Microsoft.WindowsTerminal_<versionNumber>.msixbundle file from the Assets section. To install the app, you can simply double-click on the .msixbundle file, and the app installer should automatically run. If that fails for any reason, you can try the following command at a PowerShell prompt:

# NOTE: If you are using PowerShell 7+, please run
# Import-Module Appx -UseWindowsPowerShell
# before using Add-AppxPackage.

Add-AppxPackage Microsoft.WindowsTerminal_<versionNumber>.msixbundle

Note

If you install Terminal manually:

• You may need to install the VC++ v14 Desktop Framework Package. This should only be necessary on older builds of Windows 10 and only if you get an error about missing framework packages.
• Terminal will not auto-update when new builds are released so you will need to regularly install the latest Terminal release to receive all the latest fixes and improvements!

Via Windows Package Manager CLI (aka winget)

winget users can download and install the latest Terminal release by installing the Microsoft.WindowsTerminal package:

winget install --id Microsoft.WindowsTerminal -e

Note

Dependency support is available in WinGet version 1.6.2631 or later. To install the Terminal stable release 1.18 or later, please make sure you have the updated version of the WinGet client.

Via Chocolatey (unofficial)

Chocolatey users can download and install the latest Terminal release by installing the microsoft-windows-terminal package:

choco install microsoft-windows-terminal

To upgrade Windows Terminal using Chocolatey, run the following:

choco upgrade microsoft-windows-terminal

If you have any issues when installing/upgrading the package please go to the Windows Terminal package page and follow the Chocolatey triage process

Via Scoop (unofficial)

Scoop users can download and install the latest Terminal release by installing the windows-terminal package:

scoop bucket add extras
scoop install windows-terminal

To update Windows Terminal using Scoop, run the following:

scoop update windows-terminal

If you have any issues when installing/updating the package, please search for or report the same on the issues page of Scoop Extras bucket repository.

---

Installing Windows Terminal Canary

Windows Terminal Canary is a nightly build of Windows Terminal. This build has the latest code from our main branch, giving you an opportunity to try features before they make it to Windows Terminal Preview.

Windows Terminal Canary is our least stable offering, so you may discover bugs before we have had a chance to find them.

Windows Terminal Canary is available as an App Installer distribution and a Portable ZIP distribution.

The App Installer distribution supports automatic updates. Due to platform limitations, this installer only works on Windows 11.

The Portable ZIP distribution is a portable application. It will not automatically update and will not automatically check for updates. This portable ZIP distribution works on Windows 10 (19041+) and Windows 11.

Distribution	Architecture	Link
App Installer	x64, arm64, x86	download
Portable ZIP	x64	download
Portable ZIP	ARM64	download
Portable ZIP	x86	download

Learn more about the types of Windows Terminal distributions.

---

Windows Terminal Roadmap

The plan for the Windows Terminal is described here and will be updated as the project proceeds.

Project Build Status

Project	Build Status
Terminal
ColorTool

---

Terminal & Console Overview

Please take a few minutes to review the overview below before diving into the code:

Windows Terminal

Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more.

The Terminal will also need to meet our goals and measures to ensure it remains fast and efficient, and doesn't consume vast amounts of memory or power.

The Windows Console Host

The Windows Console host, conhost.exe, is Windows' original command-line user experience. It also hosts Windows' command-line infrastructure and the Windows Console API server, input engine, rendering engine, user preferences, etc. The console host code in this repository is the actual source from which the conhost.exe in Windows itself is built.

Since taking ownership of the Windows command-line in 2014, the team added several new features to the Console, including background transparency, line-based selection, support for ANSI / Virtual Terminal sequences, 24-bit color, a Pseudoconsole ("ConPTY"), and more.

However, because Windows Console's primary goal is to maintain backward compatibility, we have been unable to add many of the features the community (and the team) have been wanting for the last several years including tabs, unicode text, and emoji.

These limitations led us to create the new Windows Terminal.

You can read more about the evolution of the command-line in general, and the Windows command-line specifically in this accompanying series of blog posts on the Command-Line team's blog.

Shared Components

While overhauling Windows Console, we modernized its codebase considerably, cleanly separating logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient STL containers, and made the code simpler and safer by using Microsoft's Windows Implementation Libraries - WIL.

This overhaul resulted in several of Console's key components being available for re-use in any terminal implementation on Windows. These components include a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, a VT parser/emitter, and more.

Creating the new Windows Terminal

When we started planning the new Windows Terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by continuing our investment in our C++ codebase, which would allow us to reuse several of the aforementioned modernized components in both the existing Console and the new Terminal. Further, we realized that this would allow us to build much of the Terminal's core itself as a reusable UI control that others can incorporate into their own applications.

The result of this work is contained within this repo and delivered as the Windows Terminal application you can download from the Microsoft Store, or directly from this repo's releases.

---

Resources

For more information about Windows Terminal, you may find some of these resources useful and interesting:

• Command-Line Blog
• Command-Line Backgrounder Blog Series
• Windows Terminal Launch: Terminal "Sizzle Video"
• Windows Terminal Launch: Build 2019 Session
• Run As Radio: Show 645 - Windows Terminal with Richard Turner
• Azure Devops Podcast: Episode 54 - Kayla Cinnamon and Rich Turner on DevOps on the Windows Terminal
• Microsoft Ignite 2019 Session: The Modern Windows Command Line: Windows Terminal - BRK3321

---

FAQ

I built and ran the new Terminal, but it looks just like the old console

Cause: You're launching the incorrect solution in Visual Studio.

Solution: Make sure you're building & deploying the CascadiaPackage project in Visual Studio.

Note

OpenConsole.exe is just a locally-built conhost.exe, the classic Windows Console that hosts Windows' command-line infrastructure. OpenConsole is used by Windows Terminal to connect to and communicate with command-line applications (via ConPty).

---

Documentation

All project documentation is located at aka.ms/terminal-docs. If you would like to contribute to the documentation, please submit a pull request on the Windows Terminal Documentation repo.

---

Contributing

We are excited to work alongside you, our amazing community, to build and enhance Windows Terminal!

BEFORE you start work on a feature/fix, please read & follow our Contributor's Guide to help avoid any wasted or duplicate effort.

Communicating with the Team

The easiest way to communicate with the team is via GitHub issues.

Please file new issues, feature requests and suggestions, but DO search for similar open/closed preexisting issues before creating a new issue.

If you would like to ask a question that you feel doesn't warrant an issue (yet), please reach out to us via Twitter:

• Christopher Nguyen, Product Manager: @nguyen_dows
• Dustin Howett, Engineering Lead: @dhowett
• Mike Griese, Senior Developer: @[email protected]
• Carlos Zamora, Developer: @cazamor_msft
• Pankaj Bhojwani, Developer
• Leonard Hecker, Developer: @LeonardHecker

Developer Guidance

Prerequisites

• You must be running Windows 10 2004 (build >= 10.0.19041.0) or later to run Windows Terminal
• You must enable Developer Mode in the Windows Settings app to locally install and run Windows Terminal
• You must have PowerShell 7 or later installed
• You must have the Windows 11 (10.0.22621.0) SDK installed
• You must have at least VS 2022 installed
• You must install the following Workloads via the VS Installer. Note: Opening the solution in VS 2022 will prompt you to install missing components automatically:
  • Desktop Development with C++
  • Universal Windows Platform Development
  • The following Individual Components
    • C++ (v143) Universal Windows Platform Tools
• You must install the .NET Framework Targeting Pack to build test projects

Building the Code

This repository uses git submodules for some of its dependencies. To make sure submodules are restored or updated, be sure to run the following prior to building:

git submodule update --init --recursive

OpenConsole.sln may be built from within Visual Studio or from the command-line using a set of convenience scripts & tools in the /tools directory:

Building in PowerShell

Import-Module .\tools\OpenConsole.psm1
Set-MsBuildDevEnvironment
Invoke-OpenConsoleBuild

Building in Cmd

.\tools\razzle.cmd
bcz

Running & Debugging

To debug the Windows Terminal in VS, right click on CascadiaPackage (in the Solution Explorer) and go to properties. In the Debug menu, change "Application process" and "Background task process" to "Native Only".

You should then be able to build & debug the Terminal project by hitting F5. Make sure to select either the "x64" or the "x86" platform - the Terminal doesn't build for "Any Cpu" (because the Terminal is a C++ application, not a C# one).

👉 You will not be able to launch the Terminal directly by running the WindowsTerminal.exe. For more details on why, see #926, #4043

Coding Guidance

Please review these brief docs below about our coding practices.

👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or write some new ones!)

This is a work in progress as we learn what we'll need to provide people in order to be effective contributors to our project.

• Coding Style
• Code Organization
• Exceptions in our legacy codebase
• Helpful smart pointers and macros for interfacing with Windows in WIL

---

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

terminal's Issues

Copying multi-line text and pasting to a file puts all text onto single line

Your Windows build number:
Microsoft Windows [Version 10.0.16299.192]

What you're doing and what's happening:
When copying a few lines from the centre of a file with Ctrl + Shift + C I'm getting multi-line text put onto a single line.

So in my scenario:

1. I ssh'd onto a Linux server using the bash for windows terminal.
2. I'd cat or vim, in this case, a JSON file as there are 6-7 lines I need from the centre of the file.
3. I then highlight and copy the lines I need with the mouse and Ctrl +Shift + S
4. I paste it into a file (middle mouse click as Ctrl + Shift + V does not work in insert mode in vim when using WSL)

The issue is that it puts all the multi-line text onto one single line separated by large amounts of white-space rather than discovering the line endings and breaking as required.

This is obviously not expected behaviour and appears to have something to do with the Windows line endings though I can only speculate this based on what I've seen and how I do not see this behaviour happen on my native Linux system.

This happens with or without "Enable 'line wrapping selection" checked and unchecked.
It seems like it is copying all of the white-space around the text even though there is non in the file.

I should note that if, for example, I copy and paste everything I'm writing here right now, it works fine.
It only seems to be when I'm in bash itself and working within that environment.

I've recorded a video of this happening too: https://youtu.be/Z-M5P7ZTJqs

What's wrong / what should be happening instead:
It should paste the multi-line content as multiple lines, not a single long line with lots of white-space.

Using Microbit serial VT100 with WSL Ubuntu gives wrong output and early hangup

Microsoft Windows [Version 10.0.17063.1000]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)
  Configure BBC Microbit according to: https://youtu.be/w_-rEYKZ3do
  I use WSL Ubuntu (most upgraded).

$ sudo chmod 666 /dev/ttyS3
[sudo] password for pi:
$ sudo cu -l /dev/ttyS3
Connected.

Press button B on BBC micro:bit.
BBC micro:bit VT100 WSL Ubuntu:
https://youtu.be/oUPFZrn_mHw

• What's wrong / what should be happening instead:
  It should look like this:
  BBC micro:bit VT100 WSLTTY 1.8.2 https://github.com/mintty/wsltty :
  https://youtu.be/pl-IIPlDeew
  Or perhaps even better like this:
  BBC micro:bit VT100 Tera Term VT:
  https://youtu.be/o8-67Y03hRk

Cmd.exe colors are not propagated to WSL

From @dulakm on January 14, 2018 12:8

Hello,

I'm not sure if this is a bug or a feature request. I hope this is the right place to ask about it.

• Your Windows build number:
  10.0.16299.125

• What you're doing and what's happening:
  When I run command gradle tasks or even cmd.exe /c gradle.bat tasks in CMD I get colorful output:
  
  When I do the same from WSL (cmd.exe /c gradle.bat tasks), the output looses the color:
  

Please, can you help me with the issue?

Thank you,
Martin

Copied from original issue: microsoft/WSL#2843

Consider targeting at 4.6.x for a better OOTB experience.

Is targeting .NET Framework 4.7 really neccessary for ColorTool?

Starting another process causes underlining to disappear

This seems to be present since RTM (tried on 1503, 1511, 1607, 1703, 1709 and fast insiders ring).

Run any program from a command prompt which displays underlined text (for example, the program in #47), but also using the 1511 ANSI support:

#include <windows.h>
#include <stdio.h>

int main(int argc, char** argv) {
  HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
  DWORD dwMode;
  GetConsoleMode(hConsole, &dwMode);
  SetConsoleMode(hConsole, dwMode | ENABLE_VIRTUAL_TERMINAL_PROCESSING);
  printf("\e[4mHello world\e[0m\n");
  SetConsoleMode(hConsole, dwMode);
}

Running this a few times gets some lines of text on the console which are underlined. I noticed when running some other processes that underlining from previous text temporarily disappears while they're running (for example, the pscp command from the PuTTY suite or OCaml's toplevel prompt ocaml). When those processes exit, the underlining of the previous text suddenly reappears.

If you then enter cmd to start a nested interpreter, then the underlining disappears from the previous text permanently (i.e. it doesn't even reappear when you type exit from the nested interpreter).

I'm not aware of any of those programs intentionally manipulating the attributes of the console cells, so I think it's reasonable to expect that the underlining should be persisting!

Bash on Ubuntu on Windows drawing issues while resizing window

Updating a Raspberry Pi with Raspbian OS using 'apt' via SSH in Bash for Windows and resizing the window during the upgrade phase (sudo apt upgrade -y) seems to have rows drawing issues.

I was able to reproduce it also within my Bash sub-system while upgrading it.

Console Cursor for Dark Grey Background Disappears

• Your Windows build number:
  10.0.16299.98

• What you're doing and what's happening:
  Changing background color of console to 'dark grey' and terminal cursor disappears.
  Demo here:
  https://twitter.com/consentfactory/status/956520606756896768

• What's wrong / what should be happening instead:
  Cursor should be appear in a contrasting color, blinking

Unicode neutral characters width

As Unicode TR11 suggested, all neutral characters map to halfwidth or narrow characters.

According to EastAsianWidth following characters are neutral:

✖ 0x2716
✚ 0x271A
✭ 0x272D
✹ 0x2739

so they should be halfwidth or narrow, but is rendered full-width in CMD.exe, which is causing terminal disarrangement.

Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.16299.125]

Add an option to print the colour table for the current scheme

There should be a way to output the colour table for the currently applied colours without having to specify and apply a scheme file. I've created a pull request which implements this as -c, --current: #3

Console doesn't handle colored regions when reflowed

• Your Windows build number: (Type ver at a Windows Command Prompt)
  FCU

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

1. Open Ubuntu session in Console
2. Execute the following:

$ cd ~/
$ mkdir temp
$ cd temp
$ mkdir hello
$ mkdir world
$ clear 
$ ls

3. Grab & drag right-hand Console window edge to resize window width

Expected:

Folders' colored background should only extend to the end of the folder name:

Actual:

Lines with folders that are last item on line extend folder background coloring to right hand end of line:

See the following for an example of where it goes very wrong:

And it gets worse when lines wrap!

References

Thanks to @jmorrill for reporting here: https://twitter.com/jmorrill/status/915982968094580736

Can we get a proper modern terminal font ?

Consolas is nice but wasn't designed to be a terminal font, it was a monospace font for programming environments, and its design goals shows when used as a console font.

The console and WSL teams really need to get the Typography team on board and design a complete and consistent terminal font that contains all characters currently still missing in Consolas, and including Asian characters only available currently when using MS Gothic/Mincho, NSimSun/SimSun-ExtB, ...

• For complete UTF-8 compatibility, it should contain all the characters in a single font, or provide a set of consistent fonts and have conhost support fonts fallback when different codepages are used in a single output (I would vote for a single font, making it easier to include Unicode console output in technical documents in Word as well).
• It should abide by terminal's monospace and double-width conventions to avoid alignment issues with formatted output coming from other environments.
• It should contain proper pixel level hinting for all box and line drawing characters to properly join, including having the full blocks and half blocks perfectly fill their space at every size, and having the patterns of several shade blocks (U+2591, U+2592, U+2593) repeat properly without visible separation from one to the next.
• It should contain Unicode characters available on other platforms and used in console apps, such as U+2190 to U+2199 arrows.

Remember this work would still benefit a more modern console (still hoping for a DX-based console), so it isn't a temporary fix, it would really benefit Windows in the long term.

List parser formats supported in console output

It would be nice to have the tool list the formats supported. Something like:

Usage:
    colortool.exe [options] <schemename>
ColorTool is a utility for helping to set the color palette of the Windows Console.
By default, applies the colors in the specified .itermcolors or .ini file to the current console window.
This does NOT save the properties automatically. For that, you'll need to open the properties sheet and hit "Ok".
Included should be a `schemes/` directory with a selection of schemes of both formats for examples.
Feel free to add your own preferred scheme to that directory.
Arguments:
    <schemename>: The name of a color scheme. ct will try to first load it as an .itermcolors color scheme.
                  If that fails, it will look for it as an .ini file color scheme.
Options:
    -?, --help     : Display this help message
    -c, --current  : Print the color table for the currently applied scheme
    -q, --quiet    : Don't print the color table after applying
    -d, --defaults : Apply the scheme to only the defaults in the registry
    -b, --both     : Apply the scheme to both the current console and the defaults.
    -v, --version  : Display the version number

Available importers:
  INI File Parser
  iTerm Parser

Official API to create a third-party console host (like pty in Unix)

Yes, a full, comprehensive pty API. It should be able to handle all kinds of console applications that run in Conhost (WSL, Win32, UWP, even 16-bit DOS programs).

SSH from bash can freeze the console when non regular characters are outputed.

Hi!

• Your Windows build number:
  Microsoft Windows [Version 10.0.16299.192]

• What you're doing and what's happening:
  Run an Ubuntu VM (mine is v16) with Golang 1.9.3 installed on it (with Virtualbox for instance).
  SSH from Windows bash onto that VM and run the following golang program:

package main

import (
	"math"
	"fmt"
)

func main() {

	var tt float32 = 1
	for j := 0; j < 5000; j++ {
		bits := uint64(math.Float32bits(tt))
		tt++
		byteCount := 4
		var bb []byte
		bb = make([]byte, 0, byteCount)
		for i := 0; i < byteCount; i++ {
			bb = append(bb, byte(bits&255))
			bits = bits >> 8
		}
		fmt.Print(string(bb))
	}
}

go run <filename>.go

• What's wrong / what should be happening instead:
  It starts outputing some characters and then freeze.
  Characters outputed:

  ?   @  @@  @  @  @  @   A  �A   A  0A  @A  PA  `A  pA  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A   B  �B B  B  �B  �B  �B  �B   B  $B  (B  ,
B  0B  4B  8B  <B  @B  DB  HB  LB  PB  TB  XB  \B  `B  dB  hB  lB  pB  tB  xB  |B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B
B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B   C  �C  �C  �C  �C  ��
C  C C          C
C  �C  �C  �C  �C  �C  �C  �C  �C  �C  �C  �C  �C  �C     �C  �C  �C  �C   C  !C  "C  #C  $C  %C  &C  'C  (C  )C  *C  +C  ,C  -C  .C  /C  0C  1C  2
3C  4C  5C  6C  7C  8C  9C  :C  ;C  <C  =C  >C  ?C  @C  AC  BC  CC  DC  EC  FC  GC  HC  IC  JC  KC  LC  MC  NC  OC  PC  QC  RC  SC  TC  UC  VC  WC
XC  YC  ZC  [C  \C  ]C  ^C  _C  `C  aC  bC  cC  dC  eC  fC  gC  hC  iC  jC  kC  lC  mC  nC  oC  pC  qC  rC  sC  tC  uC  vC  wC  xC  yC  zC  {C  |C
}C  ~C  �C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C
C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C
C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C
C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C
C C  C C  C C  C C  C C  C C  C C  C C  C C  C C  C C   D @ D  D  D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D ��
D  D @D D D D DDD       D @     D       D       D
D @
D
D
D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�
D �D �D  �D @�D �D �D  �D @�D �D �D    �D @�D �D �D  �D @�D �D �D  �D @�D �D �D  �D @�D �D �D   D @ D  D  D  !D @!D !D !D  "D @"D "D "D  #D @#D #D #
D  $D @$D $D $D  %D @%D %D %D  &D @&D &D &D  'D @'D 'D 'D  (D @(D (D (D  )D @)D )D )D  *D @*D *D *D  +D @+D +D +D  ,D @,D ,D ,D  -D @-D -D -D  .D @.
D .D .D  /D @/D /D /D  0D @0D 0D 0D  1D @1D 1D 1D  2D @2D 2D 2D  3D @3D 3D 3D  4D @4D 4D 4D  5D @5D 5D 5D  6D @6D 6D 6D  7D @7D 7D 7D  8D @8D 8D 8D
9D @9D 9D 9D  :D @:D :D :D  ;D @;D ;D ;D  <D @<D <D <D  =D @=D =D =D  >D @>D >D >D  ?D @?D ?D ?D  @D @@D @D @D  AD @AD AD AD  BD @BD BD BD  CD @CD C
D CD  DD @DD DD DD  ED @ED ED ED  FD @FD FD FD  GD @GD GD GD  HD @HD HD HD  ID @ID ID ID  JD @JD JD JD  KD @KD KD KD  LD @LD LD LD  MD @MD MD MD  N
@ND ND ND  OD @OD OD OD  PD @PD PD PD  QD @QD QD QD  RD @RD RD RD  SD @SD SD SD  TD @TD TD TD  UD @UD UD UD  VD @VD VD VD  WD @WD WD WD  XD @XD XD X
D  YD @YD YD YD  ZD @ZD ZD ZD  [D @[D [D [D  \D @\D \D \D  ]D @]D ]D ]D  ^D @^D ^D ^D  _D @_D _D _D  `D @`D `D `D  aD @aD aD aD  bD @bD bD bD  cD @c
D cD cD  dD @dD dD dD  eD @eD eD eD  fD @fD fD fD  gD @gD gD gD  hD @hD hD hD  iD @iD iD iD  jD @jD jD jD  kD @kD kD kD  lD @lD lD lD  mD @mD mD mD
nD @nD nD nD  oD @oD oD oD  pD @pD pD pD  qD @qD qD qD  rD @rD rD rD  sD @sD sD sD  tD @tD tD tD  uD @uD uD uD  vD @vD vD vD  wD @wD wD wD  xD @xD x
D xD  yD @yD yD yD  zD @zD zD zD  {D @{D {D {D  |D @|D |D |D  }D @}D }D }D  ~D @~D ~D ~D  �D @�D �D

This works perfectly fine on powershell (running the program from Windows) or within the Ubuntu native terminal (from Virtualbox interface).

Regards

[bug] cannot save background color

I know this is probably larger than the scope of this tool, but a bug is a bug is a bug is a bug.

When I use colortool with an iterm2color file, it correctly applies the background color to the console, but that color isn't saved anywhere.

Furthermore, when I manually override the iterm2color file to assign the background color to ColorTable00, it is overridden to Black (0, 0, 0) as soon as I open the Properties dialog.

I currently have to save it to defaults, then go to regedit and manually copy the key over, which is a pain.

concfg support ?

https://github.com/lukesampson/concfg

concfg looks like a really interesting tool, providing a large amount of settings for the windows console.

I wonder if it's worth the color tool being able to natively import concfg json files ?

Powershell subscript causes tmux display issues

From @serrearthur on December 7, 2017 21:35

When executing a powershell.exe script inside a tmux session, this will mess the display until the tmux session is closed.

On this picture, the left pane should be filled with text from the output of ls -al, and the right panes are missing part of their borders.

Step to reproduce :

• Install tmux (tested with tmux 2.6)
• Launch it (works even without .tmux.conf file)
• Create a new vertical pane : tmux split-window -h
• Launch a powershell.exe command : powershell.exe -Help | less
  This will mess up your display : it hides parts of your screen, will not update some data, will copy some text all over your screen, ...

Cases tested :

• Reproduced with both bash and zsh
• Reproduced even when redirecting the output of powershell : powershell.exe -Help &>/dev/null
• Reproduced with various powershell flags : powershell.exe -NoLogo -NoProfile -NonInteractive -OutputFormat Text -Help &>/dev/null
• Reproduced even without doing tmux split-window -h. However, there are only a few graphical bugs in this case. Spliting the window makes the problem clearer.
• Windows version : 10.0.17046.1000

Is this a bug ? Is there a workaround ?

---

Just as a side note, the reason I wanted to execute powershell commands is because I want to retreive the status of NUM_LOCK and CAPS_LOCK, and xset q always return false on WSL. Instead, I used powershell.exe "[console]::NumberLock" and powershell.exe "[console]::CapsLock" to get the real status.

Copied from original issue: microsoft/WSL#2731

Cosmetic issue - file path too long on WSL and it overlaps on to next line.

This only happens when using ZSH

version - Microsoft Windows [Version 10.0.16299.125]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

When booting up WSL the prompt is overlapping on to the next line. This issue only seems to occur when using longer file paths (eg '/mnt/c/Users/Lewis').

• What's wrong / what should be happening instead:

What should be happening is that the prompt and the path should be on the same line.

The right is what should be happening. https://imgur.com/a/ZeXi2

What is the licensce of the project?

Colors not applied correctly

Starting the cmd with two different ways gives Cmd Prompt in two different color variants.

Image 1:

Image 2:

I have applied color scheme with colortool -b color-theme-name and also opened Properties sheet and hit Ok as mentioned in the colortool -h. This is supposed to apply the chosen color scheme to both: current and default consoles, but surprisingly I get two different results.

The Image 1 console retains the specified color scheme while the Image 2 console displays the default legacy color scheme.

I get Image 1 color scheme when starting the console using:

1. Start + R > cmd
2. Start + X > Command Prompt (Admin)
3. Shift + Right click > Open command window here in explorer window
4. Alt + D and typing %comspec% in explorer window

and get the Image 2 color scheme using:

1. Start menu > cmd, Start + S > cmd and Start + Q > cmd
2. Start + X > Command Prompt

This is somewhat inconsistent behavior; so please improve it.

This tool is the first awesome tool we Windows CMD lovers got in a while thus we believe that it should be perfect which will eventually make command prompt great again!!

Painting issue with COMMON_LVB_UNDERSCORE in 1703 onwards

COMMON_LVB_UNDERSCORE seems to paint unreliably since Windows 10 1703 (10.0.15063) and it's still present in 10.0.17063.1000 on the fast insider ring.

Compile and run the following program multiple times from a new command prompt (I've only tried it on x64 installations):

#include <windows.h>
#include <stdio.h>

int main(void) {
  HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
  CONSOLE_SCREEN_BUFFER_INFO info;
  GetConsoleScreenBufferInfo(hConsole, &info);
  SetConsoleTextAttribute(hConsole, COMMON_LVB_UNDERSCORE | info.wAttributes);
  printf("COMMON_LVB_UNDERSCORE added to console text attributes\n");
  fflush(stdout);
  printf("Hello world\n");
  fflush(stdout);
  SetConsoleTextAttribute(hConsole, info.wAttributes);
}

The expected output is two lines of text both underlined. On my 1703 box, the first line is never underlined and, randomly, neither was the second on one run. Scroll the console to move the lines off-screen and scroll it back and the lines reappear.

Note that you have to scroll the console text itself out of the viewport and back in - moving another window over the top of the console and then off does not cause the underlining to reappear. The effect occurs regardless of whether the program is run from the machine directly or via remote desktop.

conhost crashes when Vim is run via ConEmu

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.17025.1000]

• Vim Version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 22 2017 22:02:21)
MS-Windows 64-bit console version
Included patches: 1-1213
Compiled by appveyor@APPVYR-WIN

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

1. Open a new ConEmu instance.
2. Type vim, then press the Enter key

• What's wrong / what should be happening instead:

  • conhost.exe crashes

  Faulting application name: conhost.exe, version: 10.0.17025.1000, time stamp: 0x9d420209
  Faulting module name: ntdll.dll, version: 10.0.17025.1000, time stamp: 0x174af1e9
  Exception code: 0xc0000374
  Fault offset: 0x00000000000f511b
  Faulting process id: 0x28a8
  Faulting application start time: 0x01d351c58f135167
  Faulting application path: C:\WINDOWS\system32\conhost.exe
  Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
  Report Id: ac139509-a65e-4a2d-80a2-2e7a3c48df2b
  Faulting package full name: 
  Faulting package-relative application ID: 
  

  • Vim continues running until it's terminated.
  • Vim's CPU utilization jumps significantly, pegging the CPU at 100%
  • After Vim is terminated, I get an error stating that PowerShell has stopped working.

• Other Notes:
  Similar behavior arises when attempting to run NeoVim (nvim.exe) with $env:TERM=xterm-256color

Reading cursor position from exe started from WSL

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.16299.19]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  I'm working on enabling PSReadLine to work when input is redirected. I have all the console I/O working in a plain Windows console using just ANSI escape sequences. My motivation though is to be able to run the Windows version of PowerShell under tmux, but I'm getting strange inconsistent results from the cursor position query when I start it from WSL - whether in the actual shell, tmux, or just ubuntu run pwsh.exe. Basically, the cursor position response is getting mostly auto-echoed to the console, and I'm not able to read and parse it. Since PowerShell and PSReadLine are big complicated projects, I wrote a simple line editor using just Windows APIs, but it does the same thing.

Screenshot with order of events:

1. Compile the program
2. Start it from Windows - this worked fine (see the lines test and wow it works! how cool!)
3. Start it from WSL - after the first line the cursor jumped to the top of the screen and when I hold down enter, it may read none, some, or all of the cursor position response. Usually some unpredictable portion of it.

Here is the program I'm running: https://gist.github.com/parkovski/c0af657c8371760e89c6a82febbd4f84

• What's wrong / what should be happening instead:
  It should act like it does when started from Windows - a cursor position response should send the whole thing to stdin; it shouldn't echo parts of it to the screen. Am I missing something? It seems like cmd and PowerShell without PSReadLine handle this scenario, albeit with very basic capabilities, so I'm inclined to think this is not necessarily a console bug, but some mode or setting that I'm missing.

Colortool not changing the default for VS 2017 developer command prompt

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.16299.125]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

I'm running the Developer Command Prompt for VS 2017, in admin mode.

I run the following:

colortool -b campbell

This changes the color of the current session. But if I open a new instance of the developer command prompt, only the default black & white terminal colors are being used. If I open a new regular command prompt, I see that Campbell has been applied.

Is there anyway to get this to work?

• What's wrong / what should be happening instead:

Opening a new instance of Developer Command Prompt should use the new default color theme.

This tool doens't solve "Ubuntu Bash for Windows 10" dark blue color problem?

I've changed color theme with the colortool released by Microsoft, but it didn't affected Ubuntu Bash for Windows 10.

My Windows build number: Microsoft Windows [Version 10.0.16299.98]

I'm using Ubuntu for Windows 10, to connect with my VPS through SSH, this is how it looks, and I would like to make blue a lot lighter...

Vim Cursor shape stays underscore. Not able to change it

From @ponegan on January 9, 2018 6:40

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.16299.125]

• What you're doing and what's happening / What's wrong / what should be happening instead:
  I'm using xterm-256color.
  I had been tried to change the shape of my vim cursor. I tried lots of different configuration for cursor shape (to be block) but none of them works as I put them in my .vimrc.

For example I tried some of these:
http://vim.wikia.com/wiki/Configuring_the_cursor

In the terminal I was able to change the shape of cursor to block by selecting 'large' in property as @zadjii-msft suggested in #1253. But the same trick won't work for vim. Well.... it will work at the moment I set it to 'large'. But it will reset back to underscore every time I open another file.

As this:

Anyone got a good approach on this cursor configuration?

Copied from original issue: microsoft/WSL#2821

Clicking on the console window blocks output

Windows version: 10.0.15063

What I'm doing
I've noticed that, if I click anywhere in the console window while a command is running, it seems to be blocked until I press some key to undo the mouse selection. I can reproduce it using the NodeJS REPL:

1. Open nodejs and type in a command that prints something after an interval, for instance setTimeout(() => console.log("Done"), 2000);
2. After pressing enter and before the timeout elapses, click somewhere in the console window, selecting a "unit cell" in the console
3. While this "cell" is selected by this mouse click, the output is not printed to the screen, as if the command has been blocked
4. If I press a key on the keyboard, the mouse selection is undone, and the output is printed

What should happen
Clicking on the console window should not block the output from programs already running in the console. I have faced this problem with a webserver using Express and with MongoDB. Sometimes, when debugging, I accidentally clicked on the console window, preventing requests to the webserver and database from being processed. Once I press a key to undo the mouse click selection, the request is served. In my case, I was always using stdout (printing logs), so I guess execution is being blocked until the program can write to the console.

This behavior does not happen using Bash on Linux, so I suppose it's not by design. Any help would be appreciated.
Thanks in advance.

Cannot use itermcolors scheme, Exception

Hi, while I have no problem trying .ini files .itermcolors trigger an error:

Microsoft Windows [version 10.0.15063]
(c) 2017 Microsoft Corporation. Tous droits réservés.

D:\projects\other\console\tools\ColorTool>colortool solarized_dark

Exception non gérée : System.FormatException: Le format de la chaîne d'entrée est incorrect.
   à System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   à System.Convert.ToDouble(String value)
   à ColorTool.XmlSchemeParser.parseRgbFromXml(XmlNode components, UInt32& rgb)
   à ColorTool.XmlSchemeParser.ParseScheme(String schemeName)
   à ColorTool.Program.Main(String[] args)

Status update on tabbed terminal?

Heya! Sorry about this not being a real issue. In the Powershell AMA yesterday, one of your colleagues recommended we could get in contact via this repo.

Last year, Mike Griese mentioned on Hacker News that a process-isolated, tabbed terminal was being worked on inside Microsoft. How is this progressing, and is there any way we can try builds of the updated terminal?

I suspect there's a massive bunch of Windows console fans who'd love to test your work!

ColorTool: Add modified campbell.ini with black fully black and bright white full white

This is a suggestion to add a modified version of cambell.ini (the new default console scheme) to colortool.

You'd just change two lines:

DARK_BLACK =           0,0,0 
BRIGHT_WHITE =           255,255,255

Many LCD monitors have poor enough black levels already... :)

As an aside, it would be good to use DOS-type line endings (CR/LF) in the .ini files so they can easily be edited with Notepad.

Handling Missing Numbers in ANSI Escape Sequences

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.16299.125]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

test@PC2:~$ printf "\033[31mtest\n"
test (red)
test@PC2:~$ printf "\033[31;mtest\n"
test (red)
test@PC2:~$ printf "\033[31;0mtest\n"
test (white)
test@PC2:~$

• What's wrong
  The second output is printed in red:

• What should be happening instead:

The second output should be printed in white like on Linux:

According to Wikipedia (https://en.wikipedia.org/wiki/ANSI_escape_code):

All common sequences just use the parameters as a series of semicolon-separated numbers such as 1;2;3. Missing numbers are treated as 0 (1;;3 acts like the middle number is 0, and no parameters at all in ESC[m acts like a 0 reset code).

Further details are available from:
https://superuser.com/questions/1280903/how-to-enable-colors-with-win32-openssh-and-putty

v2 console: unblocked WriteFile sets lpNumberOfBytesWritten incorrectly

A console can be frozen/paused if there is text selection (or IIRC if the user hits the Pause key in certain input modes). In that case, WriteConsole/WriteFile calls are blocked until the console is unfrozen.

With ASCII output, when a WriteFile call successfully completes that had initially been blocked, WriteFile reports the number of bytes written (via lpNumberOfBytesWritten) as nNumberOfBytesToWrite * 2 rather than nNumberOfBytesToWrite. I'd guess that it's reporting the size, in bytes, of the output after a conversion to UTF-16. I expect it to use an unconverted amount.

WriteConsoleA works as expected, as does WriteFile in either a legacy console or with the v2 console in Windows 10.0.15063.

winpty uses the "Select All" command to synchronize with a stream of output into a console, so programs running winpty hit this WriteFile change frequently. In particular, the print statement in Python 2.7 can fail, which is causing problems for people:

• platformio/platformio-atom-ide-terminal#422
• microsoft/vscode#40199
• platformio/platformio-vscode-ide#61

upstream winpty bug: rprichard/winpty#134

Affected Windows versions:

• 10.0.16257.1000
• 10.0.16299.19
• 10.0.16299.125

Repro 1 (Python 2.7):

test.py :

import sys
for i in range(20000):
    sys.stdout.write(b'.')
    sys.stdout.flush()

Run the script, then press Ctrl-A to select all text before it finishes. Then press ESC. The output looks like this:

C:\Users\rprichard>c:\Python27\python.exe test.py
.................................................................................
.................................................................................
.................................................................................
......................Traceback (most recent call last):
  File "test.py", line 3, in <module>
    sys.stdout.write(b'.')
IOError: [Errno 0] Error

Repro 2 (C++11)

#pragma comment(lib, "user32.lib") 

#include <windows.h>
#include <stdio.h>
#include <string.h>

#include <thread>

// Send "Select All", then spawn a thread to hit ESC a moment later.
static void start_selection() {
    const HWND hwnd = GetConsoleWindow();
    const int SC_CONSOLE_SELECT_ALL = 0xFFF5;
    SendMessage(hwnd, WM_SYSCOMMAND, SC_CONSOLE_SELECT_ALL, 0);
    auto press_escape = std::thread([=]() {
        Sleep(300);
        SendMessage(hwnd, WM_CHAR, 27, 0x00010001);
    });
    press_escape.detach();
}

template <typename T>
static void do_write_test(
        const char *api_name,
        T *api_ptr,
        bool use_selection) {
    if (use_selection) {
        start_selection();
    }    
    char buf[] = "1234\n";
    DWORD actual = 0;
    const BOOL ret = api_ptr(
        GetStdHandle(STD_OUTPUT_HANDLE),
        buf, strlen(buf), &actual, NULL);
    const DWORD last_error = GetLastError();
    printf("%s: %s returned %d: actual=%u LastError=%u (%s)\n",
        ((ret && actual == strlen(buf)) ? "SUCCESS" : "ERROR"),
        api_name, ret, actual, last_error,
        use_selection ? "select" : "no-select");
}

int main() {
    // Passes: Unblocked WriteConsoleA.
    do_write_test("WriteConsoleA", WriteConsoleA, false);

    // Passes: Blocked WriteConsoleA.
    do_write_test("WriteConsoleA", WriteConsoleA, true);

    // Passes: Unblocked WriteFile.
    do_write_test("WriteFile", WriteFile, false);

    // Fails: Blocked WriteFile. WriteFile returns the number of bytes
    // multiplied by 2 (the size of the UTF-16 output in bytes?).
    do_write_test("WriteFile", WriteFile, true);

    return 0;
}

Bad output:

C:\Users\rprichard>cl /nologo consolebug.cpp
consolebug.cpp

C:\Users\rprichard>consolebug
1234
SUCCESS: WriteConsoleA returned 1: actual=5 LastError=0 (no-select)
1234
SUCCESS: WriteConsoleA returned 1: actual=5 LastError=0 (select)
1234
SUCCESS: WriteFile returned 1: actual=5 LastError=0 (no-select)
1234
ERROR: WriteFile returned 1: actual=10 LastError=0 (select)

Good output:

C:\Users\rprichard>\\nas\nas\SambaShared\consolebug.exe
1234
SUCCESS: WriteConsoleA returned 1: actual=5 LastError=0 (no-select)
1234
SUCCESS: WriteConsoleA returned 1: actual=5 LastError=0 (select)
1234
SUCCESS: WriteFile returned 1: actual=5 LastError=0 (no-select)
1234
SUCCESS: WriteFile returned 1: actual=5 LastError=0 (select)

Edit: update test to reflect that (a) WriteFile does the right thing when it isn't blocked by selection, and (b) WriteConsoleA works in either case.

Background color reverted when clicking 'Properties'

This bug-tracker is monitored by Windows Console development team and other technical types. We like detail!

If you have a feature request, please post to the UserVoice.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to [email protected], referencing this GitHub issue.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

• Your Windows build number: (Type ver at a Windows Command Prompt)

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

• What's wrong / what should be happening instead:

(Note, I'm doing all of this by typing 'cmd' into my Explorer address bar...which I believe is just a proxy for running C:\Windows\System32\cmd.exe)

If I run colortool.exe solarized_light everything looks fine.

However, if I then go into the properties, it looks like this (note 'Screen Background')

and as soon as I click 'OK' (without clicking anything else in the Properties window) the background changes back to black (not sure about other colors?)

Any idea what's going on? I'd expect the Properties window to reflect the current palette and then just save those colors when I hit Ok.

Running Windows 10, Versoin 1703, Build 16251.1002

colortool: inconsistent color with iterm2

build 16299, using colortool from e024874

Repro:

• clone the iTerm2-Color-Schemes repo from https://github.com/mbadolato/iTerm2-Color-Schemes
• use colortool to apply a scheme, say Argonaut
• compare the console colors with the colors in the iTerm2 color schemes repo screenshots

Expect:

• same colors

Actual:

• different colors

Comparison:

Note how some of the values differ subtly with the original. Especially for the grey colors. Some are swallowed in the background.

Possibly related to the color space? In iterm2 xml the rgb components are companioned with a color profile (sRGB etc.)

Also, we should parse the foreground & background colors and set them in the console.

A more drastic example:

This one should be due to missing background & foreground.

iTerm2 color schemes can not be parsed when using a non-english locale

When trying to apply an iTerm2 color scheme on a computer with a German locale, the scheme can not be parsed (and applied).

Error message:

schemes\deuteranopia.itermcolors
Invalid Color
Invalid scheme - did not find 16 colors
Error loading ini file "./schemes\deuteranopia.itermcolors"
    for key "DARK_BLACK"
    the value "" is invalid
Could not find or load "schemes\deuteranopia.itermcolors"
Press any key to continue . . .

I tracked it down to Convert.ToDouble used in https://github.com/Microsoft/console/blob/1be2939f257bc89136bd6ea2ee04cdf75d12f3f0/tools/ColorTool/ColorTool/XmlSchemeParser.cs#L48 which will use the current locale to parse the value. Because we use a comma as decimal separator and the dot as group separator, the values are invalid.

I created a pull request (#1: Use invariant culture for parsing double values)

[Feat] Export current settings

Export current settings to .itermcolor or .ini files for easy backup

Paste limited to 50 chars when run in Docker container on Windows

When pasting text into powershell in a Windows container the text is truncated at 50 characters which makes for a very frustrating and unproductive user experience.

This effect is most notable in powershell becaue of an unfortuante interaction with PSReadline however unusual/undersirable behaviour is also observed in a plain cmd terminal leading to (IIUC) the conclusion that the underlying problem is with the console itself.

This issue has been previously opened in 3 separate repositories:

• PowerShell/PSReadLine#460
• moby/moby#27793
• PowerShell/PowerShell#5501

...however I'm opening it here as all those issues have been closed under the assumption that the problem lies with the console itself

Improve VS2017 detection by leveraging VSWhere.exe

With support for multiple versions of VS2017, using vswhere.exe to detect the location of an appropriate install would be easier.

Best way to use xterm ESC-sequences in scripts in Cmd e.g. bat, js, vbs, pl, py?

• Your Windows build number:
  Microsoft Windows [Version 10.0.17074.1002]

• What you're doing and what's happening:
  I want to use ESC-sequences in bat-, js-, vbs, pl, py-files in Cmd, but don't know how to switch so that they are used. I tried e.g. a program called input.js:

WScript.Echo("\x1B[1mEnter something\x1B[0m");
WScript.Echo("You entered " + WScript.StdIn.ReadLine());

And run it using cscript input.js //NoLogo. This prints:

�[1mEnter something�[0m
hello
You entered hello

• What's wrong / what should be happening instead:
  Enter something
hello
You entered hello

I can cure this by using start /wait /b before the command:
start /wait /b cscript input.js //NoLogo
Enter something
hello
You entered hello

Is start /wait /b the best way to use ESC-sequences from https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences in a bat-, js- or vbs-program?

Garbage characters after line in nano

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.17093.1000]
  Ubuntu is most updated.

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  I'm editing a file in GNU nano and when i go to the end of line there are garbage characters after it. The left part shows WSL Ubuntu with original Console and the right part wsltty 1.8.4 (based on mintty). wsltty is correct in this case.
  
  apt source beep
cd beep-1.3/
nano beep.c

• What's wrong / what should be happening instead:
  There should not be characters after the last ; on the line starting with $vent));. This bug makes it rather difficult to edit files. The colors are also different, but ought to be the same as in e.g. xterm unless one has some special color scheme. The fonts are the same teletext2.ttf but they have different sizes (16pt and 11pt, respectively) even though they look the same size. I think if one uses a font size it should be the same size on screen in different programs.

How to shield the windows environment variables?

How to shield the windows environment variables?
When I install vue on wsl, it shows a lot of executable files. like this:

There are three vue paths here, but I want to run the last one

can't see file whitch create by explorer.exe using 'ls' in wsl bash

• Your Windows build number: Microsoft Windows [Version 10.0.16299.125]

• What you're doing and what's happening:
  Using explorer.exe create a new file to "C:\Users\Administrator\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs/opt"，then using bash to 'ls' it .
  

• What's wrong / what should be happening instead: can't see this file in bash.
  

Exception with rapid PowerShell SecureString entry

Linked from: PowerShell/PowerShell#3511

I'm seeing an issue on Windows 10 1703 where typing too quickly into a Read-Host -AsSecureString prompt will forcefully terminate the running script.

For example: typing "asdf;lkjasdf;lkjasdf;lkjasd" very rapidly succession will cause the script to terminate.

The exception is not presented to the PowerShell terminal user; however it is stored in the $StackTrace variable:

   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
   at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
   at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

Be able to configure the selection highlighting behavior

When you highlight text with the Command Prompt (cmd.exe), it just inverts the
colors of whatever you selected:

However the white is a little bright for me, I would prefer gray background.
Can I change the white highlight color, if so how?

http://superuser.com/questions/1293003

[WSL] Newlines when copying from console

• Your Windows build number: Microsoft Windows [Version 10.0.16299.192]

• What you're doing and what's happening:
  Select text in a (WSL/Bash on Windows) console using the mouse and
  copying it using right mouse button.

• What's wrong / what should be happening instead:
  The resulting text (when pasted) got no newlines but lots of whitespace between the lines instead.

\033[J has wrong specification, CSI 1 J & \x1B[0J should change behavior, CSI 2 J wrong with colors

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.17083.1000]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  In Ubuntu I test with some lines on the console and these commands on last row:
  printf "\e[1;1H\e[0J"
printf "\e[1;1H\e[1J"
printf "\e[1;1H\e[2J"
printf "\e[1;1H\e[J"

• What's wrong / what should be happening instead:
  \e[1J & \e[0J should change behavior.
  \e[J does the right thing but the specification that default for xterm is 1 is probably wrong.
  \e[1;1H\e[J should do similar as \e[2J but now \e[2J doesn't seem to print spaces because background colors are not respected.
  Note the difference on the top row between printf "\e[1;1H\e[44m\e[2J" and printf "\e[1;1H\e[44m\e[J". Especially if the terminal is newly started.
  In WSLTTY 1.8.3 (based on PuTTY) there is no difference.

"For each of the sequences, the default value for if it is omitted is 1. For the following commands, the parameter has 3 valid values:

• 0 erases from the beginning of the line/display up to and including the current cursor position
• 1 erases from the current cursor position (inclusive) to the end of the line/display
• 2 erases the entire line/display"

https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#span-idtextmodificationspanspan-idtextmodificationspanspan-idtextmodificationspantext-modification

"Clears part of the screen. If n is 0 (or missing), clear from cursor to end of screen. If n is 1, clear from cursor to beginning of the screen. If n is 2, clear entire screen (and moves cursor to upper left on DOS ANSI.SYS)."
https://en.wikipedia.org/wiki/ANSI_escape_code

"J ED Erase display (default: from cursor to end of display).
ESC [ 1 J: erase from start to cursor.
ESC [ 2 J: erase whole display."
man console_codes

"CSI Ps J Erase in Display (ED).
Ps = 0 -> Erase Below (default).
Ps = 1 -> Erase Above.
Ps = 2 -> Erase All."
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

This is partly related to #41.

ColorTool: Background color not working correctly

ColorTool is not setting the background color correctly when I use it. I've tried the built-in themes and also my own .itermcolors files and they all end up varying shades of purple and pink.

Windows 10
Version 1703
Build 16251.1002

ColorTool does not work on Linux distros

Not sure this is what I should be doing, but the bash window for WSL does not get modified using this tool, so I default to an ugly color selection.

solarized itermcolors don't correspond to the provided rgb values in the solarized repository

As the title suggests, the values by colortool using the solarized itermcolors don't correspond to that in the solarized repository. I created an ini to use the values from the solarized repos:

[table]
DARK_BLACK     = 0  , 43 , 54
DARK_BLUE      = 38 , 139, 210
DARK_GREEN     = 133, 153, 0
DARK_CYAN      = 42 , 161, 152
DARK_RED       = 220, 50 , 47
DARK_MAGENTA   = 211, 54 , 130
DARK_YELLOW    = 181, 137, 0
DARK_WHITE     = 238, 232, 213
BRIGHT_BLACK   = 7  , 54 , 66
BRIGHT_BLUE    = 101, 123, 131
BRIGHT_GREEN   = 147, 161, 161
BRIGHT_CYAN    = 131, 148, 150
BRIGHT_RED     = 203, 75 , 22
BRIGHT_MAGENTA = 108, 113, 196
BRIGHT_YELLOW  = 88 , 110, 117
BRIGHT_WHITE   = 253, 246, 227

[info]
name   = solarized-dark
author = JackeJR

Bash fails to pass control characters to `cmd.exe`

Windows build number

10.0.17074.1002

What you're doing and what's happening

In Windows WSL Bash Terminal

1. Open cmd inside the Bash terminal and type any command.

sky@SkyZen:~$ cmd.exe
Microsoft Windows [Version 10.0.17074.1002]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>echo hello
echo hello
hello

2. Press ↑.

What's wrong / what should be happening instead

Actual behavior: A textual representation of the Up Arrow control key gets typed into the input field.

C:\WINDOWS\system32>^[[A

Expected behavior: Pressing ↑ will show the previous command in the input field.

C:\WINDOWS\system32>echo hello