Why is there no platform independent way of clearing aterminal?
in [Python]
|
Prev: Check in interpreter if running a debug version of python
Next: Best practice way to open files in Python 2.6+?
From: Phil Thompson on 27 Jul 2010 10:36 On Tue, 27 Jul 2010 16:02:23 +0200, Bruno Desthuilliers <bruno.42.desthuilliers(a)websiteburo.invalid> wrote: > Daniel Fetchinson a écrit : >> Hi folks, >> >> If I'm only interested in linux and windows I know I can do >> >> ################################ >> import os >> import platform >> >> if platform.system( ) == 'Linux': >> clear = 'clear' >> else: >> clear = 'cls' >> >> os.system( clear ) >> ################################ >> >> or something equivalent using os.name and friends, but was wondering >> why there is no platform independent way (i.e. the platform dependence >> is taken care of by the python stdlib) of clearing a terminal. 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. >> >> Why was clearing a terminal left out? >> > > What you're talking about is a shell, not a terminal (a terminal is a > physical device). And the shell is not necessarily part of the OS itself > (there's no shortage of shells for unices / linux systems), so it > doesn't belong to the os or platform modules. > > FWIW, I can't tell for sure since I never used any other shell than > bash, but I'm not sure your above code is garanteed to work on each and > any possible unix shell. Sorry, but that is completely wrong - the shell is irrelevant. "clear" is just a normal command line program that queries the termcap/terminfo database (possibly via the curses library) for the terminal specific sequence of characters that will clear the screen. It then writes those characters to stdout. The terminal, or (more usually these days) terminal emulator, then interprets those characters and takes the appropriate action. I'm not sure what the POSIX status of the clear command is, but I'd be surprised if it wasn't present on a UNIX/Linux system of any vintage. Phil
From: Martin Gregorie on 28 Jul 2010 16:28
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 | |