completely fails on win32/win64

[wohali]

Worth a mention in the documentation alongside punting to colorama:

c:\users\joan\desktop>pip install blessings
Downloading/unpacking blessings
  Downloading blessings-1.5.tar.gz
  Running setup.py egg_info for package blessings

Installing collected packages: blessings
  Running setup.py install for blessings

Successfully installed blessings
Cleaning up...

c:\users\joan\desktop>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from blessings import Terminal
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\blessings\__init__.py", line 3, in <module>
    import curses
  File "C:\Python27\lib\curses\__init__.py", line 15, in <module>
    from _curses import *
ImportError: No module named _curses
>>>

After installing curses on Windows from http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses :

c:\users\joan\desktop>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from blessings import Terminal
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\blessings\__init__.py", line 5, in <module>
    from fcntl import ioctl
ImportError: No module named fcntl
>>>

If I have time I'll try and work out a proper port.

[erikrose]

Very resourceful, finding a curses port. The fcntl stuff is just to get the terminal size. tigetnum('lines') and tigetnum('cols') as well as the LINES and COLS env vars are alternatives used by many libraries, but they don't update unless you continually call setupterm(). I'm not sure what the side effects are of calling that every time someone asks the terminal size.

Any research you care to do is welcome.

[ctoth]

After stumbling across this same error and performing a bit of research, I came across this recipe. Perhaps you could add it as a patch?
http://code.activestate.com/recipes/440694-determine-size-of-console-window-on-windows/
Thanks!

[asfaltboy]

There's a drop-in replacement fork for PDcurses: https://github.com/jmcb/python-pdcurses

Anyway, I saw a good soluition by google-api-python-client to enable friendly locking cross-platform: http://code.google.com/p/google-api-python-client/source/detail?r=ac147884bf0c

or even a nicer replacement using a module from grizzled-python: http://pydoc.net/grizzled-python/1.0.2/grizzled.io.filelock

[erikrose]

And http://pypi.python.org/pypi/UniCurses%20for%20Python/1.1 purports to be a PyPI packaging of PDCurses that I could depend on. Neat.

Why do you mention the file-locking stuff?

[wohali]

Because win32/win64 does not have ioctl as in
https://github.com/erikrose/blessings/blob/master/blessings/__init__.py#L5
and
https://github.com/erikrose/blessings/blob/master/blessings/__init__.py#L205

[erikrose]

google-api-python-client provides a workaround for fcntl's lockf function but not for ioctl (which would involve much deeper and darker magic). I think the best bet is to try the determine-size-of-console implementation or, failing that, to poll PDCurses (though that probably brings in the need to call setupterm() each time).

[mhammond]

Getting past the lack of ioctl isn't that big a deal, but PDCurses seems to completely stub out all of the "ti" functions. So while curses.A_BOLD exists, tigetstr(every_single_string) returns None to Python (see http://pdcurses.cvs.sourceforge.net/viewvc/pdcurses/PDCurses/pdcurses/terminfo.c?view=markup and scroll to line 167)

My quick look over the blessings code makes me think that this is a bit of a show-stopper...

[joncotton]

+1 for this issue. Using Blessings 1.5.1.

from blessings import Terminal
File "C:\Python27\lib\site-packages\blessings\__init__.py", line 5, in <module>
    from fcntl import ioctl
ImportError: No module named fcntl

[shurane]

Figured it's worth mentioning an alternative flavor of PDCurses, win32a.

[fwenzel]

Flagging this Issue with the obvious Help Wanted; from someone who knows (a lot) more about windows terminals than we/I do, and could poke at a branch for this. What's more, if win needs certain, possibly elaborate, workarounds, ideally we introduce them without littering the core codebase with it. Fun!

[yoavram]

I found a solution for fcntl on SoF.

[jquast]

The only way blessings will work on windows is with the PDCurses build mentioned by @shurane .. unfortunately, PDCurses is a non-op for all terminal capabilities and terminal types. So Terminal(kind="ansi").bright_red("txt") == u"txt".

I have plans to do resolve this by proxying (only) the terminal capabilities of terminal type "ansi" (ecma-48), which roughly matches ansi.sys and the colorama and other sequence decoders to mscvrt packages.

[zrisher]

@jquast @shurane Apologies for my lack of knowledge here, I'm pretty unfamiliar with manually managing python dependencies, but I couldn't get your strategy to work.

Combining what I found on the PDCurses for Windows ("win32a") website and the corresponding github fork's Windows readme, I:

• git clone https://github.com/Bill-Gray/PDCurses
• cd PDCurses\win32a
• make -f mingwin32.mak

And I'm presented with a bunch of new files ending in .o, .exe, and .a. If I run testcurs.exe it seems to work fine. But I have no idea how to make these files available to my python session. I'm using conda and pip to manage my install of blessings, if it helps. Since we're relying on a git fork, there's no issue tracker for that project , or I would ask this question there, but I'm hoping you may be able to easily help.

[HugoTian]

@erikrose , I am developing progress bar use blessing, and I got the same error for fcntl. I looked the source code, it is only used when getting the size of terminal. In the comments, you said

    # tigetnum('lines') and tigetnum('cols') update only if we call
    # setupterm() again.

May I know why we need those number to update, or in which case it may run into problem ?

In my current version, I just replace the code with

 return tigetnum('lines'), tigetnum('cols')

and it does not have problems in execution.

Thanks in advance

[erikrose]

@HugoTian You'd need those numbers to update only if you planned to call tigetnum. What I meant by that comment is "Here is an alternative to tigetnum which is always up to date and doesn't need setupterm() to be called repeatedly." It's also possible that those routines update more frequently on Windows; you should test it.

[erikrose]

Sticking my reply to another bug here in case I'm wrong and someone can point it out:

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.

[wohali]

Hi @erikrose ,

Actually, that's changed in Windows 10. See here: https://stackoverflow.com/questions/2048509/how-to-echo-with-different-colors-in-the-windows-command-line#38617204

Note the reply below the accepted answer that uses a very clever inline compilable .net script to achieve the same thing on OS versions earlier than Windows 10.

Or, you could add a 3rd party dependency like https://github.com/jeremejevs/cmdcolor .

[erikrose]

Wow, that's great news! I'd be happy to require Windows 10 and up and let the passage of time solve the rest of the problem. I think that's the cleanest solution. So now this is a simple matter of getting the right (ANSI) terminal capabilities returned when on Windows. If things like tigetstr exist on Windows, we can use those; otherwise, we can hard-code a lookup table in. Anyone want to take a swing?

[wohali]

As long as there's a "disable all colour codes" backward compatibility option, I'm +1 on the idea.

[natejgardner]

To be clear, the current version of blessings remains incompatible with Windows, right?

[erikrose]

@natejgardner Correct.

[retsyo]

so bad, shedskin/shedskin#260

[TedHoward]

Did blessings ever work on Windows? If so, which version? blessings looks great and docs imply it works on Windows albeit without proper colors (colorama may fix)

I'm writing a text adventure game with my 9yr old son. I was going to surprise him with color & UI. :(

[filips123]

This issue is 7 years old but without any fix... Is there any update?

You could maybe use some third-party packages for styling Windows' console. Also, Windows 10 now supports ANSI Escape Sequences. Can this be used to provide at least some functionalities?

@TedHoward You can use Windows Subsystem for Linux or Docker to use Linux terminal on Windows.

[TedHoward]

@filips123 That would work but seems like an awkward solution. Also I have a few Macs laying around I could use. colorama provides some colors, styling, and cursor navigation. Blessings would be a nice UI layer on top ... if it worked.

I just found blessed which works on Windows (https://pypi.org/project/blessed/)

[jquast]

The fork blessed is API compatible with blessings, and has Windows support since Dec 2019. Please enjoy! https://blessed.readthedocs.io/en/latest/intro.html#requirements and thank you so much, @avylove !