Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75625 > unrolled thread

cmd.exe on WIndows - problem with displaying some Unicode characters

Back to article view | Back to comp.lang.python

Contents

  cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-04 00:52 +0200
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris Angelico <rosuav@gmail.com> - 2014-08-04 09:08 +1000
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters Christian Gollwitzer <auriocus@gmx.de> - 2014-08-04 22:35 +0200
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-04 00:20 +0100
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Andrew Berg <aberg010@my.hennepintech.edu> - 2014-08-03 18:25 -0500
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-04 00:29 +0100
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris Angelico <rosuav@gmail.com> - 2014-08-04 09:39 +1000
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris Angelico <rosuav@gmail.com> - 2014-08-04 10:14 +1000
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-03 17:17 -0700
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters wxjmfauth@gmail.com - 2014-08-04 01:47 -0700
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-03 21:14 -0700
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Andrew Berg <aberg010@my.hennepintech.edu> - 2014-08-04 00:06 -0500
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Terry Reedy <tjreedy@udel.edu> - 2014-08-04 04:39 -0400
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-04 17:00 +0200
        Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-08-04 17:43 +0200
          Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-04 18:48 +0200
            Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris Angelico <rosuav@gmail.com> - 2014-08-05 03:06 +1000
              Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-04 19:22 +0200
                Re: cmd.exe on WIndows - problem with displaying some Unicode characters Terry Reedy <tjreedy@udel.edu> - 2014-08-04 15:43 -0400
        Re: cmd.exe on WIndows - problem with displaying some Unicode characters Terry Reedy <tjreedy@udel.edu> - 2014-08-04 15:17 -0400
          Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-04 22:24 +0200
            Re: cmd.exe on WIndows - problem with displaying some Unicode characters Akira Li <4kir4.1i@gmail.com> - 2014-08-05 04:51 +0400
              Re: cmd.exe on WIndows - problem with displaying some Unicode characters wxjmfauth@gmail.com - 2014-08-05 00:38 -0700
              Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-05 11:39 +0200
        Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris Angelico <rosuav@gmail.com> - 2014-08-05 06:11 +1000
        Re: cmd.exe on WIndows - problem with displaying some Unicode characters giacomo boffi <g@boffi.net> - 2014-08-04 22:53 +0200
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-08-04 10:46 +0200
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-04 02:46 -0700
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-04 02:53 -0700
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-08-04 12:24 +0200
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Andrew Berg <aberg010@my.hennepintech.edu> - 2014-08-04 05:33 -0500
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-04 11:04 -0700
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Glenn Linderman <v+python@g.nevcal.com> - 2014-08-04 11:15 -0700
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters Grant Edwards <invalid@invalid.invalid> - 2014-08-04 19:30 +0000
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Terry Reedy <tjreedy@udel.edu> - 2014-08-04 15:25 -0400
    Re: cmd.exe on WIndows - problem with displaying some Unicode characters Tony the Tiger <tony@tiger.invalid> - 2014-08-05 20:26 +0000
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters Grant Edwards <invalid@invalid.invalid> - 2014-08-05 20:41 +0000
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters Wiktor <look@signature.invalid> - 2014-08-06 00:16 +0200
        Re: cmd.exe on WIndows - problem with displaying some Unicode characters Tony the Tiger <tony@tiger.invalid> - 2014-08-06 18:27 +0000
      Re: cmd.exe on WIndows - problem with displaying some Unicode characters wxjmfauth@gmail.com - 2014-08-05 23:30 -0700

Page 2 of 2 — ← Prev page 1 [2]

#75709

On Mon, 04 Aug 2014 15:17:04 -0400, Terry Reedy wrote:

>>    I'm taking next step, so I tried to draw nice frame around menu (that's
>> why I posted yesterday).
> 
> Is there no working codepage with ascii text and the line chars? I 
> suppose I am not surprised if not.

  With single line (└┘┌┐─│├┤┬┴┼) and double line (╣║╗╝╚╔╩╦╠═╬) - many
codepages, CP852 for sure.

  With corners/crosses where single and double lines meet (╖╘╡╢╕╜╛╞╟
╧╨╤╥╙╘╒╓╫╪) - I know only one: CP437.
  
  But I can't have both - Polish letters and all those line chars, so I
can't do this fancy frame from first post with Polish strings inside. There
will be simpler version instead.

-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#75716

Wiktor <look@signature.invalid> writes:

> On Mon, 04 Aug 2014 15:17:04 -0400, Terry Reedy wrote:
>
>>>    I'm taking next step, so I tried to draw nice frame around menu (that's
>>> why I posted yesterday).
>>
>> Is there no working codepage with ascii text and the line chars? I
>> suppose I am not surprised if not.
>
>   With single line (└┘┌┐─│├┤┬┴┼) and double line (╣║╗╝╚╔╩╦╠═╬) - many
> codepages, CP852 for sure.
>
>   With corners/crosses where single and double lines meet (╖╘╡╢╕╜╛╞╟
> ╧╨╤╥╙╘╒╓╫╪) - I know only one: CP437.
>
>   But I can't have both - Polish letters and all those line chars, so I
> can't do this fancy frame from first post with Polish strings inside. There
> will be simpler version instead.

Unicode has line drawing characters [1]. win_unicode_console [2] allows
to print Unicode in cmd.exe. win_unicode_console and colorama will
probably conflict. You could look at the source to see how hard to
combine both functionalities.

[1] http://en.wikipedia.org/wiki/Box-drawing_character
[2] https://pypi.python.org/pypi/win_unicode_console

btw, blessings [3] provides an easy-to-use interface if you need to add
colors and move text in a terminal. It claims that it also supports
colors on Windows if used with colorama.

[3] https://pypi.python.org/pypi/blessings/


--
Akira

[toc] | [prev] | [next] | [standalone]

#75721

Code pages, console, codings, characters, ...
From my GUI interactive interpreter mimicking a "dos box".
Question marks instead of .notdef glyph (ev. replaced chars)
displayed in a real console. (tested)



%%%%%%%%%%%%%


>>> # the gui
>>> sys.stdout.encoding
'<unicode>'
>>> # the cp852 available chars
>>> a = ''
>>> for i in range(0x20, 0x3000):
...     try:
...         a = a + chr(i).encode('cp852').decode('cp852')
...     except Exception:
...         pass
...         
>>> len(a)
224
>>> a
'
!"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW
XYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\xa0¤§¨«¬\xa
d°´¸»ÁÂÄÇÉËÍÎÓÔÖ×ÚÜÝßáâäçéëíîóôö÷úüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾
ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽžˇ˘˙˛˝─│┌┐└┘├┤┬┴┼═║╔╗╚╝╠╣
╦╩╬▀▄█░▒▓■'

>>> # changing the console code page
>>> sys.stdout.encoding ='cp852'
>>> sys.stdout.encoding
'cp852'
>>> # some cp852 strings
>>> s = """\
... ┌──────────────────────────────────────────────────────────┐
... │abcúüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽž│
... └──────────────────────────────────────────────────────────┘"""
>>> s2 = """\
... ╔══════════════════════════════════════════════════════════╗
... ║abcúüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽž║
... ╚══════════════════════════════════════════════════════════╝"""
>>> print(s)
┌──────────────────────────────────────────────────────────┐
│abcúüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽž│
└──────────────────────────────────────────────────────────┘
>>> print(s2)
╔══════════════════════════════════════════════════════════╗
║abcúüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽž║
╚══════════════════════════════════════════════════════════╝
>>> # changing and using cp437...
>>> # with cp852 chars
>>> sys.stdout.encoding = 'cp437'
>>> sys.stdout.encoding
'cp437'
>>> print(s)
┌──────────────────────────────────────────────────────────┐
│abcúü?????????????????????????????????????????????????????│
└──────────────────────────────────────────────────────────┘
>>> print(s2)
╔══════════════════════════════════════════════════════════╗
║abcúü?????????????????????????????????????????????????????║
╚══════════════════════════════════════════════════════════╝
>>> # or cp1252...
>>> sys.stdout.encoding = 'cp1252'
>>> sys.stdout.encoding
'cp1252'
>>> print(s)
????????????????????????????????????????????????????????????
?abcúüý????????????????????????????????????Šš????????????Žž?
????????????????????????????????????????????????????????????
>>> print(s2)
????????????????????????????????????????????????????????????
?abcúüý????????????????????????????????????Šš????????????Žž?
????????????????????????????????????????????????????????????
>>> # reset
>>> sys.stdout.encoding = '<unicode>'
>>> sys.stdout.encoding
'<unicode>'
>>> print(s2)
╔══════════════════════════════════════════════════════════╗
║abcúüýĂ㥹ĆćČčĎďĐđĘęĚěĹ弾ŁłŃńŇňŐőŔŕŘřŚśŞşŠšŢţŤťŮůŰűŹźŻżŽž║
╚══════════════════════════════════════════════════════════╝
>>> 
>>> # end
>>>

jmf

[toc] | [prev] | [next] | [standalone]

#75723

On Tue, 05 Aug 2014 04:51:15 +0400, Akira Li wrote:

> Unicode has line drawing characters [1]. win_unicode_console [2] allows
> to print Unicode in cmd.exe. win_unicode_console and colorama will
> probably conflict. You could look at the source to see how hard to
> combine both functionalities.
> 
> [1] http://en.wikipedia.org/wiki/Box-drawing_character
> [2] https://pypi.python.org/pypi/win_unicode_console
> 
> btw, blessings [3] provides an easy-to-use interface if you need to add
> colors and move text in a terminal. It claims that it also supports
> colors on Windows if used with colorama.
> 
> [3] https://pypi.python.org/pypi/blessings/

  [2] - indeed does not work with colorconsole/colorama. And I'm not that
smart to combine those two functionalities. :-)
  [3] - maybe it works with colorama (colorama for coloring, and blessing
for positioning text), but now I don't even use colorama. I use
colorconsole to color AND position text, and I find it very handy. Don't
think that blessing+colorama would be more easy-to-use.

  Thanks, I really appreciate every proposition to fix original problem you
all are giving me - I check them all. 
  But you need to understand, that I'm already OK with those cmd.exe
limitations, and really not trying to achieve look of frame from first
post. I'm OK with those single-only and double-only lines.

  Now my game would look like this:
https://dl.dropboxusercontent.com/u/10544563/kolony_prntscr.png [*]
and I think it's very neat.

Wiktor

*) it's mocup (I don't have 'window manager' yet, so I have to show/
activate/deactivate/etc. every window by hand), but still

-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#75708

On Tue, Aug 5, 2014 at 5:17 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> Is there no working codepage with ascii text and the line chars? I suppose I
> am not surprised if not.

That would be codepage 437. I grew up with that on DOS, as the one and
only 256-character set, and then when we moved to OS/2 and actual
codepages, we always configured 437,850 (that is, 437 as primary, with
850 as a secondary if we wanted it). Trouble is, it doesn't have
non-basic letters, and the OP needs to write Polish text. I'd be not
at all surprised if there are characters he needs that aren't in
CP437.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75711

Wiktor <look@signature.invalid> writes:

>   I'm not starting from scratch. I'm using packages 'termcolor', 'colorama'
> and 'colorconsole'

the 'urwid' package could be useful for similar projects but <cite>
requires Linux, OSX, Cygwin or other unix-like OS</cite> so I guess
it's of no use for you...

ciao
                                          g

[toc] | [prev] | [next] | [standalone]

#75673

On Mon, Aug 4, 2014 at 2:17 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
> For this OP problem, it is mostly a matter of finding a fixed-width font
> that supports the box drawing characters and the Polish characters that are
> desired.  Lucida Console has a fair repertoire, and Consolas has a fair
> repertoire, in the fixed-width font arena. There may be others, documented
> on Polish language web sites that I wouldn't know about, and I don't know
> enough Polish to be sure those I mentioned suffice.

Not really.  We haven’t had to play the “custom fonts for our
language” game for quite some time.  Consolas and Lucida Console work
just fine for Polish (though Consolas sometimes hiccups on capital
characters in some environments).  The characters are:

ĄĆĘŁÓŃŚŹŻ
ąćęłóńśźż

Most fonts — especially the ones included with modern OSes — support
all 18 of them.

So, this is a non-issue.  The real issue is Windows being an idiot
when it comes to CLI, which is oh so surprising to everyone who had to
work with it — considering the choice of the outdated and quirky
cmd.exe interpreter, or PowerShell, which has ultra-verbose
human-unfriendly commands and works in the same cmd.exe window (there
is a thing named PowerShell ISE, which circumvents cmd.exe; I have no
idea whether all the Unicode issues apply to that, too)

-- 
Chris “Kwpolska” Warrick <http://chriswarrick.com/>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#75677

[Multipart message — attachments visible in raw view] — view raw

On 8/3/2014 10:06 PM, Andrew Berg wrote:
> On 2014.08.03 23:14, Glenn Linderman wrote:
>> Having read a bit about ConEmu, it seems that it is a "pretty face" built on
>> top of Windows Console, by screen scraping the real (but hidden) Windows
>> Console, and providing a number of interesting display features and modes. So
>> while it adds functionality to the Windows Console interface, it doesn't seem
>> like it is likely to fix bugs or resolve issues with code pages, font
>> selection, or Unicode character repertoires, which are the issues of this
>> thread and the bug I referenced earlier.
>>
>> Can anyone with ConEmu installed refute this interpretation of its functionality?
>>
> If you run cmd in it, you will still need to use cp65001.
Or some workaround. The latest workaround in the issue I referenced does 
not require cp65001 either, for output, at least.

> This is not necessary
> for  (or applicable to) other applications (such as a Python interpreter) run
> directly.
How does one "directly run" another application using ConEmu? That 
wasn't clear from what I found to read. It sounded like you run ConEmu, 
run one or more shells within it, and launch programs from those shells? 
And so it was also unclear if a program launched from some batch file 
would have to have the batch file launched from ConEmu, also. Or does 
ConEmu grab the execution association for batch files to make that work 
more automatically?

> ConEmu can use any arbitrary font available on the system. As I have
> said, I have been able to display Unicode output on it from an application
> written in Python. No mojibake, no replacement characters, just the exact
> characters one would expect.
> I do not know the internals of ConEmu and how it interacts with conhost and
> whatever else, but I have not found a need to since it has just worked for me.
So you may not know the internals of ConEmu, but I presume you know the 
internals of your Python applications. What encodings do you use for 
stdout for those applications? Do you set up the Python environment 
variables that specify some particular encoding, in the ConEmu 
environment (or does it)? Because the default Python IO encoding in 
Windows seems to be obtained from the configured code page.

Of course the biggest problem with much free and open source software is 
the documentation; I wasn't able to find specific answers to all my 
questions by reading the ConEmu wiki. Maybe some of it would be clearer 
if I installed it, and your "just worked" comment is certainly 
encouraging me to "just try it", but while trying it may help me figure 
it out, adding another package to separately install for my users gives 
more complexity. See if you can push me over the edge :)

[toc] | [prev] | [next] | [standalone]

#75678

[Multipart message — attachments visible in raw view] — view raw

On 8/4/2014 1:39 AM, Terry Reedy wrote:
> On 8/3/2014 6:52 PM, Wiktor wrote:
>>
>> Hi,
>>
>> as OO programming exercise, I'm trying to port to Python one of my 
>> favorite
>> game from early'90 (Atari 65XL/XE) - Kolony (here's video from original
>> version on C64 https://www.youtube.com/watch?v=UFycYOp2cbE, and here's
>
> This appears to be an actual text screen, no graphics.
>
>> video from modern rewritten (for Atari emulators) version: Kolony 2106
>> https://www.youtube.com/watch?v=eX20Qqqm5eg - you get the idea? ;-)).
>
> This appears to be text boxes on a graphics screen.
>
>> OO Design is one thing, but I want to make it look as near as 
>> possible to
>> the original (those windows-like menus in console window).
>
> Which original? the C64 or Atari.  The important characteristic of 
> both is that both have multiple overlapping popup boxes. This means 
> that either you or a widget framework much keep track of stacking 
> order and how to restore what was hidden when a box goes away or is 
> moved down in the stacking order. I would not be surprised if the 
> Atari had at least a rudimentary widget framework.
>
> > I tried to use
>> 'standard' Unicode characters (I can see that most of my Windows 
>> monospaced
>> fonts have them) to draw frame around menu. Something like this:
>>
>>   ┌──────────────╖
>>   │ Construction ║
>>   │ Production   ║
>>   │ Research     ║
>>   │ Exploration  ║
>>   ├··············╢
>>   │ Next turn    ║
>>   ╘══════════════╝
>>
>> (I like the look of double lines on right and at the bottom)
>> But when I try to print those characters, I get an error:
>>
>> | Traceback (most recent call last):
>> |   File "E:\Moje dokumenty\python\kolony\menu.py", line 14, in <module>
>> |     """
>> |   File "C:\Python34\lib\encodings\cp852.py", line 19, in encode
>> |     return codecs.charmap_encode(input,self.errors,encoding_map)[0]
>> | UnicodeEncodeError: 'charmap' codec can't encode character '\u2556' 
>> in position 1
>> | 6: character maps to <undefined>
>
> You have two separate problems with running in the windows console.
>
> 1. The character issue. If you run a program to just print the above 
> from an Idle editor, so that the output is printed to the Idle shell, 
> there should be no problem.
> >>> print('\u2556'*10)
> ╖╖╖╖╖╖╖╖╖╖
> But characters are not your real issue.
>
> 2. The random access issue. The MS console in normal use is like a 
> serial printer or terminal. Once a line is printed, it cannot be 
> changed. I looked at the video and the program randomly accesses a 24 
> or 25 line x 80 column screen, overprinting existing characters at 
> will and reversing black on white versus white of black at will.  
> MSDOS screens recognized standard ANSI screen control codes once the 
> ANSI.SYS driver was installed, which was fairly normal. But cmd.exe is 
> actually a regression from MS-DOS in that it apparently will not allow 
> this.  Or it is a hugh pain.
>
> You could get a program that emulates a full-screen ANSI terminal, and 
> learn to use ANSI control codes.  Or you could use a tkinter (tk) Text 
> widget. People have written at least serial terminal emulators for 
> Text, but I did not find a full-screen.
>
> Using tkinter, I would try making each box a separate text box placed 
> in a frameand let tkinter worry about displaying them correctly and 
> detecting which box get a mouse click or <enter> key.
>
I've never used the API from Python but random console access is 
documented at 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687404%28v=vs.85%29.aspx

[toc] | [prev] | [next] | [standalone]

#75680

On 08/04/2014 11:53 AM, Glenn Linderman wrote:
>
> I've never used the API from Python but random console access is
> documented at
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms687404%28v=vs.85%29.aspx
>

Would using the API from Python involve doing the wrapping yourself or 
do you know about an existing package for the job ?

By the way (and off-topic), how would you do it on Linux?

Wolfgang

[toc] | [prev] | [next] | [standalone]

#75681

On 2014.08.04 04:46, Glenn Linderman wrote:
> How does one "directly run" another application using ConEmu? That wasn't clear
> from what I found to read. It sounded like you run ConEmu, run one or more
> shells within it, and launch programs from those shells? And so it was also
> unclear if a program launched from some batch file would have to have the batch
> file launched from ConEmu, also. Or does ConEmu grab the execution association
> for batch files to make that work more automatically?
When you open a new console, the dialog will ask you to supply a path to an
executable you want to run. Any arbitrary CLI application will work. I don't
understand your question about batch files. If you mean to ask if ConEmu will
snatch a console opened by executing a batch file outside of ConEmu, yes, it
can do that. I highly suggest actually using the program and doing some tests
of your own to see how it works.

>> ConEmu can use any arbitrary font available on the system. As I have
>> said, I have been able to display Unicode output on it from an application
>> written in Python. No mojibake, no replacement characters, just the exact
>> characters one would expect.
>> I do not know the internals of ConEmu and how it interacts with conhost and
>> whatever else, but I have not found a need to since it has just worked for me.
> So you may not know the internals of ConEmu, but I presume you know the
> internals of your Python applications. What encodings do you use for stdout for
> those applications? Do you set up the Python environment variables that specify
> some particular encoding, in the ConEmu environment (or does it)? Because the
> default Python IO encoding in Windows seems to be obtained from the configured
> code page.
I use UTF-8. Open the Python interpreter directly in ConEmu and see what you get.

> Of course the biggest problem with much free and open source software is the
> documentation; I wasn't able to find specific answers to all my questions by
> reading the ConEmu wiki. Maybe some of it would be clearer if I installed it,
> and your "just worked" comment is certainly encouraging me to "just try it",
> but while trying it may help me figure it out, adding another package to
> separately install for my users gives more complexity. See if you can push me
> over the edge :)
It certainly would make things much clearer if you were to actually use the
program. Documentation tends to assume (and reasonably so, IMO) that you intend
to do some hands-on learning.
I can give no advice on deploying this to your users other than to say ConEmu
works well as a tool for command line power users on Windows, but does not
provide much ROI when it is simply an implementation detail for a single
program. If you want to save your users the hassle, I would definitely
recommend a graphical environment. If I had realized that you intended your
application to be widely deployed, I would have simply recommended that from
the start.

On a side note, you would have run into similar issues on *nix systems where a
significant amount of your users would be using the "C" locale and have no idea
what it is, why it causes them problems, or how to change it.

[toc] | [prev] | [next] | [standalone]

#75701

[Multipart message — attachments visible in raw view] — view raw

On 8/4/2014 3:33 AM, Andrew Berg wrote:
> If you want to save your users the hassle, I would definitely
> recommend a graphical environment. If I had realized that you intended your
> application to be widely deployed, I would have simply recommended that from
> the start.

Graphical environments are good for some things, command line 
environments are good for other things.

Unicode capability is beneficial in both.

Many of the software tools I create and distribute are command line 
utilities, for people that use command lines anyway.  The problems arise 
when they are multilingual, and need to use diverse character repertoires.

[toc] | [prev] | [next] | [standalone]

#75702

[Multipart message — attachments visible in raw view] — view raw

On 8/4/2014 3:24 AM, Wolfgang Maier wrote:
> On 08/04/2014 11:53 AM, Glenn Linderman wrote:
>>
>> I've never used the API from Python but random console access is
>> documented at
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms687404%28v=vs.85%29.aspx 
>>
>>
>
> Would using the API from Python involve doing the wrapping yourself or 
> do you know about an existing package for the job ?

I haven't used the API from Python. I haven't checked PyWin32 to see if 
it already wraps that API like it wraps so many other APIs. I haven't 
Googled using "python" and "WriteConsoleOutput" to see if other packages 
may exist to do the job. But these are the things that I would do if I 
had a need to write a program like yours, since I know that the console 
does, in fact, support random access.

>
> By the way (and off-topic), how would you do it on Linux?

Off topic? It is still about doing it using Python, no?

I believe that most Unix terminal emulators, which are used for running 
shells and command lines, support cursor controls, and I believe most of 
them have a mode that emulates the DEC VT-52 terminal, one of which I 
had physical access to at the "computer lab" at the university I 
attended so many years ago. The VT-52 defined escape sequences to move 
the cursor around on the screen, providing random access. Text-based, 
screen-oriented programs such as emacs leveraged such capabilities quite 
effectively.

There may be something better today, I haven't used Unix for a dozen 
years now, and the usage at that time was database development not 
text-based graphics. I've used Linux only on my web host, and a little 
experimentation on a local machine I installed it on here, until the 
machine died, and I didn't do any text-based graphics in either of those 
circumstances either.  So probably college was the last time I used 
text-based graphics, but that was using RSTS and DECsystem 20 (forget 
the name of the OS for that machine) on VT-52 terminals. But I've noted 
with amusement that the VT-52 (and later enhanced models) are still 
supported by Unix/Linux terminal emulators and X system.

Unix abstracts that cursor motion using "curses" and I believe there are 
curses implementations for Windows as well, but I've not attempted to 
use curses from Python on either Unix or Windows.


>
> Wolfgang
>

[toc] | [prev] | [next] | [standalone]

#75705

On 2014-08-04, Glenn Linderman <v+python@g.nevcal.com> wrote:

> I believe that most Unix terminal emulators, which are used for running 
> shells and command lines, support cursor controls, and I believe most of 
> them have a mode that emulates the DEC VT-52 terminal,

I'm not aware of any that are in common use, but there may be some
niche VT52 emulators somewhere I don't know about.  All the widely
used terminal emulators are some flavor of ANSI (for you DEC guys,
VT100 and later) rather than VT52.

-- 
Grant Edwards               grant.b.edwards        Yow! All of life is a blur
                                  at               of Republicans and meat!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#75704

On 8/4/2014 6:24 AM, Wolfgang Maier wrote:
> On 08/04/2014 11:53 AM, Glenn Linderman wrote:
>>
>> I've never used the API from Python but random console access is
>> documented at
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms687404%28v=vs.85%29.aspx
>>
>>
>
> Would using the API from Python involve doing the wrapping yourself or
> do you know about an existing package for the job ?

The packages Wiktor is using, 'termcolor', 'colorama'
and 'colorconsole' - (all on PyPI), must be using WriteConsoleOutput.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#75751

On Mon, 04 Aug 2014 00:52:29 +0200, Wiktor wrote:

> okumenty\python\kolony\menu.py", line 14, in <module>

This works for me on Linux:

---8<-----------------
# coding:utf-8

test = """
 ┌──────────────╖
 │ Construction ║
 │ Production   ║
 │ Research     ║
 │ Exploration  ║
 ├··············╢
 │ Next turn    ║
 ╘══════════════╝
"""

print test
---8<-----------------

And the output from that code:

~/Downloads $ python ./test.py

 ┌──────────────╖
 │ Construction ║
 │ Production   ║
 │ Research     ║
 │ Exploration  ║
 ├··············╢
 │ Next turn    ║
 ╘══════════════╝


Any example code that you can't get working? Perhaps somebody out there 
can come up with some ideas.

I know that Unicode can be crazy.

BTW, which version of Python do you use? I use 2.7.3.


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#75752

On 2014-08-05, Tony the Tiger <tony@tiger.invalid> wrote:
> On Mon, 04 Aug 2014 00:52:29 +0200, Wiktor wrote:
>
>> okumenty\python\kolony\menu.py", line 14, in <module>
>
> This works for me on Linux:
>
> ---8<-----------------
> # coding:utf-8
>
> test = """
>  ┌──────────────╖
>  │ Construction ║
>  │ Production   ║
>  │ Research     ║
>  │ Exploration  ║
>  ├··············╢
>  │ Next turn    ║
>  ╘══════════════╝
> """

But can you do Polish as well?  IIRC, that was the catch: encodings
that the windows terminal emulator understood that could do Polish
couldn't do double-lines and vice-versa.

I was a bit surprised when all that stuff rendered properly in slrn
runnnig in a terminal emulator.  I must have done a better job with
locales and fonts that I thought...

-- 
Grant Edwards               grant.b.edwards        Yow! Did you move a lot of
                                  at               KOREAN STEAK KNIVES this
                              gmail.com            trip, Dingy?

[toc] | [prev] | [next] | [standalone]

#75763

On 05 Aug 2014 20:26:08 GMT, Tony the Tiger wrote:

> On Mon, 04 Aug 2014 00:52:29 +0200, Wiktor wrote:
> 
>> okumenty\python\kolony\menu.py", line 14, in <module>
> 
> This works for me on Linux:

  I believe you, but I use Windows and its cmd.exe (as mentioned in
subject).

-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#75807

On Wed, 06 Aug 2014 00:16:37 +0200, Wiktor wrote:

>   I believe you, but I use Windows and its cmd.exe (as mentioned in
> subject).

Yes, I know that. My point was obviously aimed at your behind. Fair 
enough I won't bother you again. I have better things to do.

l8r


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#75782

Le mardi 5 août 2014 22:26:08 UTC+2, Tony the Tiger a écrit :
> 
> This works for me on Linux:
> 
> 

It works on *your* linux, because *your* linux is
automagically configured in the way the device that
hosts "unicode" (the console in that case) "works
in utf-8" (most probably).

On a "Russian" linux using koi8 or a "French" linux
using iso-8859-15, the problem is exacly similar as
on Windows. This is valid for any OS.

In essence, assuming the hosting device is "in utf-8"
is as wrong as assuming it is in, eg. cp852 or any
encoding.

This has nothing to do with Unicode.

jmf

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web