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

[Daniel Fetchinson]

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?

Cheers,
Daniel

 

[Bruno Desthuilliers]

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.

 

[Grant Edwards]

Daniel Fetchinson a ?crit :

What you're talking about is a shell, not a terminal (a terminal is a
physical device).

No, what he's talking about is clearing a terminal (or a terminal
emulator). They both work the same, the only difference is whether
the terminal software is running on dedicated hardware or on
general-purpose hardware.

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.

True, but clearing a terminal or terminal emulator has nothing to do
with the shell. It's done using an in-band control/escape sequence
that's indepedent of the shell being used. His example accomplishes
this using an executable named 'clear' which knows how to use
terminfo/termcap (I forget which one) to send the proper escape
sequence to the terminal.

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.

Again, the shell is irrelevent.

 

[Phil Thompson]

Daniel Fetchinson a écrit :

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

 

[Bruno Desthuilliers]

Grant Edwards a écrit :

No, what he's talking about is clearing a terminal (or a terminal
emulator). They both work the same, the only difference is whether
the terminal software is running on dedicated hardware or on
general-purpose hardware.

(snip)

I stand corrected.

 

[Daniel Fetchinson]

Hi folks,

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.

After getting the technicalities out of the way, maybe I should have asked:

Is it only me or others would find a platform independent python API
to clear the terminal useful?

Cheers,
Daniel

 

[John Nagle]

Grant Edwards a écrit :

(snip)

I stand corrected.

I immediately thought of using the "curses" module, but that's
UNIX-only, or at least it's not in the ActiveState Python distro.

John Nagle

 

[Grant Edwards]

After getting the technicalities out of the way, maybe I should have asked:

Is it only me or others would find a platform independent python API
to clear the terminal useful?

I write a lot of command-line programs, and I can't remember the last
time time I wanted to clear a terminal. But then again, pretty much
all of my programs are designed so that they can be used as filters.

About 10 years ago I did need to do a text-mode UI (menus, popups,
text-entry, etc.), and I used newt.

 

[Terry Reedy]

After getting the technicalities out of the way, maybe I should have asked:

Is it only me or others would find a platform independent python API
to clear the terminal useful?

One problem is, Where would you put it? The OS module is for system
calls, mostly based on posix. The system call involved in clearing a
terminal is a write string call. *nix puts terminal control in a
separate library.

Another is, what next? clear_line? Pretty soon, we are back to curses.

Still another problem is that most of us do not have terminals; we have
screens and use them as such. OS-independent full-screen graphics/game
libraries have clear screen commands. Similary, GUI systems have means
of clearing text and canvas widgets, but should not be able to clear the
whole screen. The turtle module has a clear command for its canvas,
which would be the same regardless of underlying gui. So we already have
several OS independent clear commands.

On Windows, the DOS clr command only works withing a text-mode command
window (once called a dos window). The same thing (os.system('clr')
within an IDLE shell uselessly flashes a blank command window, which
then disappears. Yeah, it is too bad windows did not use the obvious
'clear' like everyone? else. If command windows still imitate or can be
set to imitate ansi terminals, then I would think curses is your best bet.

 

[Tim Harig]

I immediately thought of using the "curses" module, but that's
UNIX-only, or at least it's not in the ActiveState Python distro.

pdcurses:

http://pdcurses.sourceforge.net/

is a cross platform curses implementation that is available for Windows.
I wonder how difficult it would be to embed into the Python curses module
as a backup for systems where curses is not natively available. This would
allow Python to provide cross platform charactor mode manipulation.

 

[Ulrich Eckhardt]

After getting the technicalities out of the way, maybe I should have
asked:

Is it only me or others would find a platform independent python API
to clear the terminal useful?

There are two kinds of programs:
1. Those that process input to output. If one of those suddenly started by
clearing my screen, I'd just dump it. Also, if output is redirected to a
file or piped into another program, that is basically useless or even
hurting, since you then end up with control sequences in the file.

2. Those that provide a text-based interactive UI. Those typically not only
clear the screen, but also control its whole layout and content, so there
you don't only need ways to clear the screen but also to position the
cursor or draw boxes etc. In that case you need a full "curses" library.

Summary: No, I don't see the need for such an API.

Cheers!

Uli

 

[Jonathan Hartley]

There are two kinds of programs:
1. Those that process input to output. If one of those suddenly started by
clearing my screen, I'd just dump it. Also, if output is redirected to a
file or piped into another program, that is basically useless or even
hurting, since you then end up with control sequences in the file.

2. Those that provide a text-based interactive UI. Those typically not only
clear the screen, but also control its whole layout and content, so there
you don't only need ways to clear the screen but also to position the
cursor or draw boxes etc. In that case you need a full "curses" library.

Summary: No, I don't see the need for such an API.

Cheers!

Uli

I don't know much, but just in case the following is useful to anyone:

There is a Windows program called 'ansicon', which when installed (run
with '-i'), will modify all future Windows cmd shells to correctly
intercept and interpret ANSI escape codes for colors, cursor movement,
and:

\e[#J ED: Erase Display

which I presume is what is under discussion here. I understand there
are other historical ANSI drivers which were responsible for achieving
a similar thing under Windows, but this is the method I currently use
(on XP) and am very happy with.

Also, and probably less usefully, personally I do wish Python provided
a cross platform mechanism for simple terminal control like clearing
and colored text. Since ANSI codes are used everywhere except Windows,
it would make sense to base such a system on them. So I started a pure
Python implementation of a crude ANSI driver, on PyPI as 'colorama'.
It does nothing on non-windows systems, but on Windows it patches
sys.stdout with a stream-like object, in order to filter out ANSI
codes and convert them into Win32 terminal control calls. It currently
only works with colors and brightness, but I would love to extend it
to cover other ANSI codes such as 'clear screen'. It is doubtless
riddled with errors and misunderstandings, and I would love any
feedback helping me do a better job.

Best regards,

Jonathan

 

[Daniel Fetchinson]

After getting the technicalities out of the way, maybe I should have

There are two kinds of programs:
1. Those that process input to output. If one of those suddenly started by
clearing my screen, I'd just dump it. Also, if output is redirected to a
file or piped into another program, that is basically useless or even
hurting, since you then end up with control sequences in the file.

2. Those that provide a text-based interactive UI. Those typically not only
clear the screen, but also control its whole layout and content, so there
you don't only need ways to clear the screen but also to position the
cursor or draw boxes etc. In that case you need a full "curses" library.

Summary: No, I don't see the need for such an API.

Okay, that makes perfect sense, thanks for the exaplanation!
I'll just live with the platform.system( ) check for this particular
problem then.

Cheers,
Daniel

 

[Daniel Fetchinson]

After getting the technicalities out of the way, maybe I should have

I don't know much, but just in case the following is useful to anyone:

There is a Windows program called 'ansicon', which when installed (run
with '-i'), will modify all future Windows cmd shells to correctly
intercept and interpret ANSI escape codes for colors, cursor movement,
and:

\e[#J ED: Erase Display

which I presume is what is under discussion here. I understand there
are other historical ANSI drivers which were responsible for achieving
a similar thing under Windows, but this is the method I currently use
(on XP) and am very happy with.

Also, and probably less usefully, personally I do wish Python provided
a cross platform mechanism for simple terminal control like clearing
and colored text. Since ANSI codes are used everywhere except Windows,
it would make sense to base such a system on them. So I started a pure
Python implementation of a crude ANSI driver, on PyPI as 'colorama'.
It does nothing on non-windows systems, but on Windows it patches
sys.stdout with a stream-like object, in order to filter out ANSI
codes and convert them into Win32 terminal control calls. It currently
only works with colors and brightness, but I would love to extend it
to cover other ANSI codes such as 'clear screen'. It is doubtless
riddled with errors and misunderstandings, and I would love any
feedback helping me do a better job.

Thanks, I didn't know about 'colorama' before but it surely looks promising!
I'll look into it for future reference, once in a while I like having
pretty output without the hassle of 'curses' or other complicated
stuff.

Cheers,
Daniel

 

[Emile van Sebille]

On 7/28/2010 4:23 AM Daniel Fetchinson said...

Okay, that makes perfect sense, thanks for the exaplanation!
I'll just live with the platform.system( ) check for this particular
problem then.

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

Emile

 

[Jonathan Hartley]

There are two kinds of programs:
1. Those that process input to output. If one of those suddenly started by
clearing my screen, I'd just dump it. Also, if output is redirected to a
file or piped into another program, that is basically useless or even
hurting, since you then end up with control sequences in the file.

2. Those that provide a text-based interactive UI. Those typically not only
clear the screen, but also control its whole layout and content, so there
you don't only need ways to clear the screen but also to position the
cursor or draw boxes etc. In that case you need a full "curses" library.

Summary: No, I don't see the need for such an API.

Cheers!

Uli

Hey,

Your point seems good and I don't mean to contradict, but out of
interest, what do you think about an example like the following:

I want to write a quick script which, notices whenever I save my
source code, and re-runs the unit tests, displaying the output. I
think I'd like it to clear the terminal before each re-run of the
tests, so that it's immediately obvious what is output from the
current run, as opposed to previous runs. Then I can keep my editor
focussed, but leave that running in a terminal and trust it to simply
display the current output from my tests.

I did dash off a quick and dirty version of this once which did a
system 'clear' or 'cls' depending on the platform, but to my dismay I
found that on Windows this caused focus to jump briefly to the
terminal every time it ran 'clear' (!), making it extremely annoying
in use. So I wished there had been a simple cross-platform way to
clear the terminal. (this, and printing colored text, was my initial
use case for starting 'colorama')

Is this a silly desire of mine, or simply an uncommon edge case that
therefore isn't really significant?

Best regards,

Jonathan

 

[Jonathan Hartley]

Hey,

Your point seems good and I don't mean to contradict, but out of
interest, what do you think about an example like the following:

I want to write a quick script which, notices whenever I save my
source code, and re-runs the unit tests, displaying the output. I
think I'd like it to clear the terminal before each re-run of the
tests, so that it's immediately obvious what is output from the
current run, as opposed to previous runs. Then I can keep my editor
focussed, but leave that running in a terminal and trust it to simply
display the current output from my tests.

I did dash off a quick and dirty version of this once which did a
system 'clear' or 'cls' depending on the platform, but to my dismay I
found that on Windows this caused focus to jump briefly to the
terminal every time it ran 'clear' (!), making it extremely annoying
in use. So I wished there had been a simple cross-platform way to
clear the terminal. (this, and printing colored text, was my initial
use case for starting 'colorama')

Is this a silly desire of mine, or simply an uncommon edge case that
therefore isn't really significant?

Best regards,

  Jonathan

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.

 

[Neil Cerutti]

I want to write a quick script which, notices whenever I save
my source code, and re-runs the unit tests, displaying the
output. I think I'd like it to clear the terminal before each
re-run of the tests, so that it's immediately obvious what is
output from the current run, as opposed to previous runs. Then
I can keep my editor focussed, but leave that running in a
terminal and trust it to simply display the current output from
my tests.

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.

 

[Thomas Jollans]

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 upon http://adamv.com/dev/python/curses/ -- this
is probably the only reasonable way to get a useful curses API on
Windows: forget the DOS box.

 

[Jonathan Hartley]

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.