Why is there no platform independent way of clearing a terminal?
in [Python]
|
From: Jonathan Hartley on 28 Jul 2010 12:01 On Jul 28, 4:45 pm, Jonathan Hartley <tart...(a)tartley.com> wrote: > On Jul 28, 8:08 am, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote: > > > > > Daniel Fetchinson wrote: > > > 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 > > > -- > > Sator Laser GmbH > > Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 > > 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.
From: Neil Cerutti on 28 Jul 2010 12:06 On 2010-07-28, Jonathan Hartley <tartley(a)tartley.com> wrote: > 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. -- Neil Cerutti
From: Thomas Jollans on 28 Jul 2010 12:47 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 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.
From: Jonathan Hartley on 28 Jul 2010 13:02 On Jul 28, 5:47 pm, Thomas Jollans <tho...(a)jollans.com> 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. :-)
From: Thomas Jollans on 28 Jul 2010 13:31
On 07/28/2010 07:02 PM, Jonathan Hartley wrote: > On Jul 28, 5:47 pm, Thomas Jollans <tho...(a)jollans.com> 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. |