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

Reverse text not showing up properly when using screen over ssh #4411

Closed
DMLou opened this issue Jan 30, 2020 · 7 comments
Closed

Reverse text not showing up properly when using screen over ssh #4411

DMLou opened this issue Jan 30, 2020 · 7 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@DMLou
Copy link

DMLou commented Jan 30, 2020

Whenever I run screen on a remote ssh session, the bottom line's reverse text as configured in my screenrc file doesn't seem to work properly. I use slightly customized versions of Solarized Light as my themes in both PuTTY and Windows Terminal. However, the same behavior appears even when using the default Campbell theme.

Environment

Windows build number: Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0
Windows Terminal version (if applicable): 0.8.10091.0

Windows OpenSSH connection to CentOS 7 Linux box

Steps to reproduce

While I originally saw the issue when ssh'ing to a Linux machine, I noticed they also appear when running screen in a local Ubuntu session. I'm including both reproductions here.

Remote reproduction

  1. Use the attached screenrc.txt file as the screen config file on the Linux host you're ssh'ing to
  2. ssh to the Linux host
  3. Run screen (screen -c screenrc.txt will override the default config with the attached file)

Local reproduction

  1. Use the attached screenrc.txt file as the screen config file on for your local Ubuntu session
  2. Start an Ubuntu session
  3. Run screen (screen -c screenrc.txt will override the default config with the attached file)

screenrc.txt

Expected behavior

The bottom line of the terminal should be in reverse text with the current screen highlighted, as shown in the attached PuTTY screenshot:

putty

Actual behavior

Reverse text doesn't work properly as shown in the attached screenshots from Windows Terminal. I've attached both my custom theme as well as the default Campbell theme.

windows terminal
windows terminal Campbell

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jan 30, 2020
@j4james
Copy link
Collaborator

j4james commented Jan 30, 2020

It would probably help if you attached a copy of the actual color scheme you are using (both for PuTTY and WT), because I don't think you'll get the effect you want with most standard color schemes.

The way screen works (as I understand it), the main window area is rendered with the default background color, while the status bar is rendered as "white" on "black". In most color schemes, the default background color is going to be the same as the "black" color, so the status bar will not be reversed. If you want to get that reversed effect, you'd need to set the default background to a light color, while leaving your "black" defined as a dark color.

That said, even with the color scheme setup correctly, it still won't work in Windows Terminal because of issue #293. It should work in a conhost shell though.

In short, I suspect this is a duplicate of #293 (or maybe #2661). I'd like to see the color scheme you're using to be sure though.

@DMLou
Copy link
Author

DMLou commented Jan 30, 2020

That's fine. Here is the color scheme I'm currently using in WT:

{
            "name": "Solarized Light Custom",
            "foreground": "#073642",
            "background": "#FDF6E3",
            "black": "#FDF6E3", // For reversed text
            "red": "#DC322F",
            "green": "#859900",
            "yellow": "#B58900",
            "blue": "#268BD2",
            "purple": "#D33682",
            "cyan": "#2AA198",
            "white": "#073642", // For reversed text
            "brightBlack": "#000000",
            "brightRed": "#CB4B16",
            "brightGreen": "#586E75",
            "brightYellow": "#657B83",
            "brightBlue": "#839496",
            "brightPurple": "#6C71C4",
            "brightCyan": "#93A1A1",
            "brightWhite": "#c007a1"
        }

Note that I saw the same problem using the default Campbell scheme as well (albeit obviously with different colors), although I'm not ruling out that my tweaked scheme is also broken.

Here's the link to the PuTTY scheme I'm using: https://github.com/altercation/solarized/tree/master/putty-colors-solarized

@DMLou
Copy link
Author

DMLou commented Jan 30, 2020

Oh, and I just tested it in a conhost shell and it worked fine.

@j4james
Copy link
Collaborator

j4james commented Jan 30, 2020

OK, that makes sense. The PuTTY solarized scheme has a light background color and a dark black, so that would give you a "reversed" status line (and looking at the Windows Terminal schemes, I see that the light versions are setup that way too, but they won't work correctly until #293 is fixed). Your custom scheme above has the black and background colors the same, so I wouldn't expect it to show a reversed status.

@j4james
Copy link
Collaborator

j4james commented Jan 30, 2020

And just to be clear, Campbell also has the black and background colors the same, so again I wouldn't expect it to show the reversed status. The same goes for most "dark" color schemes - there might sometimes be a slight difference in color between black and the default background, but it wouldn't be reversed like it is with a "light" scheme.

@DHowett-MSFT
Copy link
Contributor

Yeah -- running this in conhost using the "experimental terminal settings" (where conhost tries to support 18 instead of 16 colors), I can see that the default background and the black status line are actually different. If they ever resolve to the same color value, Terminal will crush them into the same value.

This is definitely a /dup of #293 and #2661. Thanks all!

@ghost
Copy link

ghost commented Jan 31, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jan 31, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jan 31, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

3 participants