1445653 - Support blessings colourization on Windows

Status: NEW

(Firefox Build System :: Bootstrap Configuration, defect)

Description

[Andrew Halberstadt [:ahal]]

This comes from bug 1445624.

Did a bit of digging on colourization on Windows. This is a long standing issue with blessings:
https://github.com/erikrose/blessings/issues/21

The first problem is that curses is missing by default. I was able to fix that by installing it from here (it doesn't appear to exist on pypi):
https://www.lfd.uci.edu/~gohlke/pythonlibs/#curses

After that error was fixed, there's another missing dependency on fcntl (which is unix only). I found a very hacky workaround here:
https://stackoverflow.com/a/25471508

But a better solution might be to try and replace fcntl with the portalocker module:
https://github.com/WoLpH/portalocker

This would ideally be upstreamed to blessings, but could be implemented in python/mozterm at first for testing/expediency.

In summary, I believe it should be possible for someone sufficiently motivated to get blessings-based colouriaztion working with their mozilla-build terminal right now. But getting it to a state where it "just works" out of the box will be a decent amount of work. I think it's at least worth investigating/prototyping.

Comment 1

[Erik Rose [:erik][:erikrose]]

> But a better solution might be to try and replace fcntl with the portalocker module:
https://github.com/WoLpH/portalocker
> This would ideally be upstreamed to blessings, but could be implemented in python/mozterm at first for testing/expediency.

I think you followed some bad breadcrumbs there. While locking is one thing you can do with the fcntl module, that's not what we're using it for: we're using it to get the size of the terminal (ioctl(descriptor, TIOCGWINSZ, '\000' * 8)). So portalocker (which doesn't define an "ioctl" implementation) won't do it. However, I'd (as the author of blessings) be happy to add some Windows-specific code that measures terminals, if only we could figure out what it is.

The greater issue, which I want to make sure is clear, is that Windows doesn't control its command-line text formatting with escape codes multiplexed into the text stream. Unless you want to limit Windows use to bash-on-Windows or some other terminal emulator, I don't think there's a way to map the escape codes blessings returns to the necessary Windows API calls, because there isn't the opportunity. Blessings returns strings, and the caller prints them when it wants, if at all; blessings would have no way of intercepting the escape codes and calling Windows APIs unless it took over the responsibility of printing.

What is feasible is to simply keep blessings from crashing on Windows, basically stubbing out all the escape codes so they do nothing. It's unfortunate, but we'd really need a higher-level API here.

Comment 2

[Andrew Halberstadt [:ahal]]

(In reply to Erik Rose [:erik][:erikrose] from comment #1)
> I think you followed some bad breadcrumbs there. While locking is one thing
> you can do with the fcntl module, that's not what we're using it for: we're
> using it to get the size of the terminal (ioctl(descriptor, TIOCGWINSZ,
> '\000' * 8)). So portalocker (which doesn't define an "ioctl"
> implementation) won't do it. However, I'd (as the author of blessings) be
> happy to add some Windows-specific code that measures terminals, if only we
> could figure out what it is.

Ah ok, thanks for the correction.

> The greater issue, which I want to make sure is clear, is that Windows
> doesn't control its command-line text formatting with escape codes
> multiplexed into the text stream. Unless you want to limit Windows use to
> bash-on-Windows or some other terminal emulator, I don't think there's a way
> to map the escape codes blessings returns to the necessary Windows API
> calls, because there isn't the opportunity. Blessings returns strings, and
> the caller prints them when it wants, if at all; blessings would have no way
> of intercepting the escape codes and calling Windows APIs unless it took
> over the responsibility of printing.

Does this include the mingw64 terminal that comes with mozilla-build? I don't think we need to care about native Windows support.

> What is feasible is to simply keep blessings from crashing on Windows,
> basically stubbing out all the escape codes so they do nothing. It's
> unfortunate, but we'd really need a higher-level API here.

The 'mozterm' module already does this:
https://searchfox.org/mozilla-central/source/python/mozterm/mozterm/terminal.py#48

I'm sure it could be implemented more elegantly within blessings itself, but the existing solution works well enough for our use cases that I'm not overly motivated to make it better.

Comment 3

[Erik Rose [:erik][:erikrose]]

Actually, it turns out this is eminently solveable on Windows >=10! https://github.com/erikrose/blessings/issues/21#issuecomment-373568731. I'd encourage us to go that way.

> Does this include the mingw64 terminal that comes with mozilla-build?

Good question. Try printing some ANSI escape sequence there, like 'print "\033[31mRED!"' in Python, and see if it comes out in color.

Comment 4

[Andrew Halberstadt [:ahal]]

(In reply to Erik Rose [:erik][:erikrose] from comment #3)
> > Does this include the mingw64 terminal that comes with mozilla-build?
> 
> Good question. Try printing some ANSI escape sequence there, like 'print
> "\033[31mRED!"' in Python, and see if it comes out in color.

It doesn't work. But excellent news about Windows 10, sounds like we could fix that in blessings and then this bug could simply be used for upgrading to the latest version in-tree. I personally don't care very much about supporting older versions of Windows, the non-colourized fallback that currently exists should be good enough.

Comment 5

[Erik Rose [:erik][:erikrose]]

Great! I'd be happy to review a blessings PR.