Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why is there no platform independent way of clearing a terminal?

Reply
Thread Tools

Why is there no platform independent way of clearing a terminal?

 
 
Thomas Jollans
Guest
Posts: n/a
 
      07-28-2010
On 07/28/2010 07:02 PM, Jonathan Hartley wrote:
> On Jul 28, 5:47 pm, Thomas Jollans <(E-Mail Removed)> wrote:
>> On 07/28/2010 06:01 PM, Jonathan Hartley wrote:
>>
>>
>>
>>> Oh, plus, while we're on this subject:

>>
>>> Am I right that curses in Python stdlib doesn't work on Windows, and
>>> there is currently no simple way to fix this?

>>
>>> Also, is it crazy to imagine that if colorama was pushed through to
>>> completion (ie. to support a majority of the relevant ANSI codes) then
>>> Python's stdlib curses module, unmodified, would suddenly just work on
>>> Windows? (after a call to 'colorama.init()')

>>
>>> I presume these ideas are oversimplifications or just plain wrong. If
>>> anyone would care to correct my misunderstandings, I'd be very
>>> grateful.

>>
>> Correct: it's not THAT simple.
>>
>> Python's curses module is a (I'm not sure how thin) wrapper around the
>> good old UNIX curses (ncurses, ...) library. This is written in C, not
>> Python, so it doesn't use Python's sys.stdout object to do I/O.
>>
>> I haven't had a look at colorama, but it sounds like it hooks into
>> sys.stdout, or Python file objects anyway. Far, far above the layer
>> curses does I/O on. So, if you ported a normal curses library to
>> Windows, colorama wouldn't help you a bit.
>>
>> It might be possible to write a curses-compatible library that works
>> with cmd.exe. Maybe. But, even if it's possible, I don't think it's
>> easy, and I especially don't think it would be particularly rewarding.
>>
>> Also, I just stumbled uponhttp://adamv.com/dev/python/curses/-- this
>> is probably the only reasonable way to get a useful curses API on
>> Windows: forget the DOS box.

>
>
>
>> ncurses ... is written in C, not
>> Python, so it doesn't use Python's sys.stdout object to do I/O.

>
> Ah, I should have spotted that. Of course. Thanks for the
> enlightenment.
>
> And Neil Cerutti, I think I'll just email the whole source tree to
> myself, and have a script that scans my inbox, unzips source trees and
> runs their tests. Much nicer.


use version control! Use mercurial, commit often, and add a commit-hook
that runs tests. Then you can even set up a separate repository that
your script automatically pushes your changes to if they pass the tests
cleanly.
 
Reply With Quote
 
 
 
 
Neil Cerutti
Guest
Posts: n/a
 
      07-28-2010
On 2010-07-28, Jonathan Hartley <(E-Mail Removed)> wrote:
> And Neil Cerutti, I think I'll just email the whole source tree
> to myself, and have a script that scans my inbox, unzips source
> trees and runs their tests. Much nicer.


Don't forget to clear the screen, though. That ties the whole
program together.

--
Neil Cerutti
 
Reply With Quote
 
 
 
 
Tim Harig
Guest
Posts: n/a
 
      07-28-2010
On 2010-07-28, Thomas Jollans <(E-Mail Removed)> wrote:
> It might be possible to write a curses-compatible library that works
> with cmd.exe. Maybe. But, even if it's possible, I don't think it's
> easy, and I especially don't think it would be particularly rewarding.


http://pdcurses.sourceforge.net/

It would be rewarding as it would make writing cross-platform charactor
mode applications possible. Using curses for the interface makes a lot of
sense because it is already supported by almost every Unix/POSIX platorm,
so re-implementation is only required for those odd platforms (Windows)
where it does not exist natively,; because well documented on the internet
and in print; and because a huge number of people are already familiar with
its API.

If licensing permits, I don't think it would be too difficult difficult to
embed something like pdcurses into the existing curses module to use as a
backup for platforms where curses does not already exist. If not, there
cannot be much difference to writing a terminal emulator that runs inside
the windows console and there are a *huge* number of terminal emulators
available for ansi/vt100 terminals. Add a termcap database mechanism and
an embedded emulator can easily convert the excape codes into actions for
the console.
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      07-28-2010
On Wed, 28 Jul 2010 09:01:38 -0700, Jonathan Hartley wrote:

> Also, is it crazy to imagine that if colorama was pushed through to
> completion (ie. to support a majority of the relevant ANSI codes) then
> Python's stdlib curses module, unmodified, would suddenly just work on
> Windows? (after a call to 'colorama.init()')
>

Curses was originally built on top of termcap, a much simpler and more
primitive library. Its abilities are:
- read the termcap database to find and load the capability list
of the terminal identified as the TERM environment variable.
- write a named capability to the screen. If the capability isn't
defined for the current terminal its silently ignored.
- fill in x, y and write the cursor movement string
- thats about it.

Its easy enough to find termcap databases. They're just text files
containing a block of attribute values for each terminal, normally
including ANSI terminals, Linux consoles, X-terms etc. They are also
fairly easy to parse, even in vanilla C, so parsing one on Python should
be a breeze. Termcap format specs and lists of standard attribute names
are easy enough to find too.

IOW, if you extend colorama to read its codes from a termcap database
you'll have a basic but easily portable character console handler that
can at least clear the screen, move the cursor and, if the screen has the
capability, change the colour of characters or make them bold/dim/blink
etc.

To give you an idea of how complex this is, I've re-implemented termcap
in Java for my own purposes. It amounts to 1100 lines of fairly well
spaced and commented Java or about 340 statements, which were estimated
by counting lines containing semicolons.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      07-29-2010
Neil Cerutti wrote:
> Perhaps emailing the tests to yourself would be a good solution.
> Every tme the tests ran, you'd get a new email containing the
> results.


Nice idea, only that it's even less portable and requires manual setup...

;^)

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      08-01-2010
In message <(E-Mail Removed)>, Daniel
Fetchinson wrote:

> Sure, there are many different terminals and many different operating
> systems but in many areas python managed to hide all these complexities
> behind a well defined API.


Once upon a time, there were indeed many different kinds of actual physical
terminals.

However, they are all extinct now. All that’s left is software emulations.
And the one emulation they all have in common is the DEC VT100.

So just assume you’re displaying on one of those:

sys.stdout.write("\x1b[2J")

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      08-01-2010
In message <i2q3sk$3pf$(E-Mail Removed)>, Tim Harig wrote:

> It would be rewarding as it would make writing cross-platform charactor
> mode applications possible.


I thought Windows users were allergic to command lines.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      08-01-2010
In message <(E-Mail Removed)>, Emile van
Sebille wrote:

> If all else fails, repeating 24 (or 40,60?) lines feeds clears the
> screen cross platform.


Depending on the height of the terminal window...
 
Reply With Quote
 
Tim Harig
Guest
Posts: n/a
 
      08-01-2010
On 2010-08-01, Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:
> In message <i2q3sk$3pf$(E-Mail Removed)>, Tim Harig wrote:
>
>> It would be rewarding as it would make writing cross-platform charactor
>> mode applications possible.

>
> I thought Windows users were allergic to command lines.


To the best of my knowledge, there have never been any documentated
cases of computer software related alleries. There are however several
chemicals used in the process of constructing computer hardware componets
which have been linked to allergy illnesses. Maybe Windows users are
simply allergic to their computers.
 
Reply With Quote
 
Mark Lawrence
Guest
Posts: n/a
 
      08-01-2010
On 01/08/2010 06:17, Tim Harig wrote:
> On 2010-08-01, Lawrence D'Oliveiro<(E-Mail Removed)_zealand> wrote:
>> In message<i2q3sk$3pf$(E-Mail Removed)>, Tim Harig wrote:
>>
>>> It would be rewarding as it would make writing cross-platform charactor
>>> mode applications possible.

>>
>> I thought Windows users were allergic to command lines.

>
> To the best of my knowledge, there have never been any documentated
> cases of computer software related alleries. There are however several
> chemicals used in the process of constructing computer hardware componets
> which have been linked to allergy illnesses. Maybe Windows users are
> simply allergic to their computers.


Windows users biggest allergy is to this strange world that involves
"make" on other boxes, whatever that is, it strikes me as rather
archaic. Personally I find double clicking on an msi file rather easier.

Regards.

Mark Lawrence.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Platform-independent way for storing application data Jan Thom Java 15 02-19-2009 04:19 PM
Launching an independent Python program in a cross-platform way (including mac) =?iso-8859-1?B?QW5kcuk=?= Python 8 05-01-2007 11:47 AM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Platform independent way to play an mp3 file Gandalf Python 1 08-18-2004 11:13 AM
Platform-independent way to refer to execute path MK Python 1 06-25-2003 05:43 PM



Advertisments