0

hyper terminal with wsl bash

I have for some time been experiencing weird behavior with the colors my terminal displays. Above is a screenshot of bash (from Windows Linux Subsystem) inside of Hyper terminal. You can see that the colors start out alright, but then I get a bunch of permission issues after an ls, and everything goes wrong. The gray background then persists indefinitely.

While I don't have a screenshot, I have witnessed the same behavior inside of Powershell within VSCode as well - so I am hesitant to call this an issue with Hyper. It seems like once an error comes through, or the shell feels the need to display a color for some reason, everything goes wild.

Additionally, I've tried with ls --color=auto with no luck - the same results are produced.

Is anyone aware of a Windows / bash / WSL setting that will keep this from happening?

Edit: I've found that this highlight respects whatever default "Screen Background" color is set in the "Defaults" option within the Bash on Ubuntu on Windows settings pane, but only once certain commands are invoked (like in my above screenshot)? Does this make sense to someone more knowledgeable than myself?

enter image description here

4
  • Does this happen whenever / wherever you do an ls,  or only in some directories? Commented Apr 14, 2018 at 23:19
  • @Scott any directory. Also, in switching over to zsh, it happens automatically on login.
    – lase
    Commented Apr 15, 2018 at 0:11
  • A major element of debugging is to trace causes to effects.  If I press four buttons at once, and a light turns on, I don’t know which of the buttons caused it (or whether it was a combination).  Your image shows a directory listing that includes “Permission denied” error messages, and then files of three different types (color schemes) — and then, you have (apparently) redacted the image. (Or do you really have some blurred entries and some blank entries?) This muddies the waters.  … (Cont’d) Commented Apr 15, 2018 at 17:34
  • (Cont’d) …  Your question would be clearer if you showed an ls listing with one file and no errors, and then say that the same thing happens, no matter what type the file is. … … … P.S. It’s common for ls --color=auto to be the default.  You might want to try ls --color=none. Commented Apr 15, 2018 at 17:34

2 Answers 2

2

Getting to the bottom of this, I found out the solution was to set the default colors in the WSL settings to have a "Screen Background" color of black (#000). I attempted setting to my desired color as mentioned in Scott's answer, however this didn't work. It appears that any of the colors that come through from WSL are additive, so any color changes would combine & clash with background colors in 3rd party programs (Hyper, VSCode).

1

Your update clarifies the situation.  Trivially, programs tell the terminal to display text by writing the text to the terminal.  A less obvious fact is that programs can command the terminal to do various other actions (e.g., move the cursor, or erase (parts of) the screen) by writing non-displaying characters to the terminal.  There are a few individual characters that do things (e.g., Backspace and Carriage Return to move to the left, and Tab to move to the right).  But generally they are sequences of characters, almost always beginning with Escape, and so they are known as “escape sequences”.  Back in the 1970s and 1980s, when terminals were hardware products, every vendor chose their own escape sequences, and it was chaos.  Over time, a standard has evolved.

One interesting group of escape sequences is the Select Graphic Rendition (SGR) family, which controls how displayable text is displayed.  This includes properties like bold, italic, underline, and color.  Typically, after displaying text in a style other than the default, a program will try to return the terminal to its default display scheme.  There are escape sequences to turn off bold, italic, and underline, but they are not supported as widely as the ones to turn on those properties.  There are escape sequences to set the color to white foreground on a black background, but that’s not great, because the user might prefer a different default scheme.  So programs that use color typically end by sending the reset sequence — and that switches the terminal to its default display scheme, as specified in the properties.

TL;DR Programs like pwd that just display text, just display text.  Programs that display text in color end by resetting the terminal to its default colors, and they stay in effect until some other program writes an escape sequence to change them again.

This leaves the question: why does the terminal start in white-on-black mode?  Maybe you have something in one of your initialization files (.profile, .bashrc, etc.) that explicitly sets those colors.

The solution is to change the default properties to what you want (e.g., white text on a black background).  You seem to have found the appropriate dialog; just change the screen background color to black and click on “OK”.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .