Fix / Support for Screen ?

[GChalony]

I use screen to launch long running programs over SSH, and when I discovered Enlighten I figured it would be really cool to use it to monitor the running process.
Unfortunately it seems enlighten doesn't like screen too much (or is it the terminal? sorry I'm new to the terminal world).

• The loading character doesn't seem to be recognized
• I use two progress bar, but the second one seems to multiply everytime it restarts to 0.

I don't know if it's relevant, but the program is running on a Debian 10 on a screen.xterm-256color terminal, to which I'm connected via SSH in a WSL environment using Windows Terminal.
However everything looks nice in the same environment/terminal when I run it locally.

Concerning the support requirements :

• The terminal must be detectable programmatically
  echo $STY

• Cursor movements
  I would guess that that comes from Xterm ?

• Terminal dimensions
  tput cols / rows seems to work, not sure if that's enough.

Tell me if I missed anything ;) thanks for you awesome work btw!

[avylove]

Thanks for reporting! Screen is already supported, we just need to figure out why you're having issues in that configuration. I just need a little bit of information to further troubleshoot this.

• What version of Enlighten are you running?
• Can I get some sample code that demonstrates the issue? Or confirm the issue exists with example code from the documentation
• Do you see the issue just running screen without SSHing to another system?
• What version of WSL are you using, 1 or 2?

[GChalony]

Thanks for the quick reply :)

I'm running enlighten 1.6.0 and WSL2.

I don't actually see the pb when I run the same code in screen on my local computer, though obviously it's not exactly the same configuration (windows for one thing). So maybe it's SSH related ?

Minimum example

import logging
import enlighten
import time

logging.basicConfig(level=logging.DEBUG)

manager = enlighten.get_manager()
progress = manager.counter(total=100, desc='Prog')

for i in range(100):
    logging.getLogger(__name__).info('Running at step {}'.format(i))
    print(i)
    progress.update()
    time.sleep(0.2)

manager.stop()

Which gives me

over SSH and

locally.

[GChalony]

Edit: I just realised the multiplying progressbars bug was my wrongdoing, I recreated a new one at each loop, sorry 🙏

[avylove]

Is it working as expected now?

[GChalony]

Nop, the screenshots above still show the format pb :)

[avylove]

Just to be sure we're on the same page, you don't see the issue under these scenarios?

• Locally on WSL2
• Locally on Debian
• Locally on WSL2 under Screen
• Remotely on Debian without Screen

You do see the issue:

• Remotely on Debian under Screen

[GChalony]

I don't see the issue

• Locally on WSL2 ✔️
• Locally on Debian ❌ I have no way to test this as it is a remote server
• Locally on WSL2 under Screen ✔️
• Remotely on Debian without Screen ✔️

I do see the issue

• Remotely on Debian under Screen ✔️

[avylove]

When you SSH without screen, do the bars show up like they do locally (solid blocks) or do they show up as diamonds?

Do you have the same behavior if you use CMD or powershell instead of Windows Terminal?

Do you have a way of testing ssh under screen from another Linux system?

[GChalony]

Yes, in SSH without screen the bars show correctly.

CMD and PowerShell (tested in WSL2) show the same behavior (works without screen, doesn't with).

And tested from another Debian 10 machine, the same problem appears.

[avylove]

What is strange to me are those diamonds. That tells me screen is not passing unicode correctly. Try starting screen with -U or ctrl-a :utf8 on.

Also, what version of Python are you using?

[GChalony]

Hurray ! screen -U ... did it ✨
I'm happy with that, but if you want to investigate more tell what info you need ;) I'm running python 3.7.3.

[avylove]

It makes sense. Essentially Enlighten is using Unicode because it detects it in the locale on the remote system, but if screen or screen in combination with SSH doesn't know it should be using Unicode, it won't interpret the characters correctly. Unfortunately, I don't really have a way to detect that. I was testing with Fedora and openSUSE and I didn't have the issue, so I'm guessing it's related to the distro's default settings. I can try to add something to the FAQ.