Thank you for a very quick, informative and concise response.
> BTW: don't forget to attach a handler to the window-size-change
> signal (SIGWINCH) so that you know when your terminal changes sizes
Do you mean something like this?
import signal, os
# terminal_info contains the example from my first post
from terminal_info import get_terminal_size
TERMINAL_SIZE = get_terminal_size()
def update_terminal_size(signum, frame):
global TERMINAL_SIZE
TERMINAL_SIZE = get_terminal_size()
signal.signal(signal.SIGWINCH, update_terminal_size)
while True:
# Do lots of IO (fishing for exceptions...)
open('/a/large/file').read()
print TERMINAL_SIZE
The docs for the signal module (http://docs.python.org/lib/module-signal.html)
say that
"""
When a signal arrives during an I/O operation, it is possible that the I/O
operation raises an exception after the signal handler returns. This is
dependent on the underlying Unix system's semantics regarding interrupted
system calls.
"""
So this is what I'm trying to provoke in the final while loop. In this case I
get no exceptions (hooray!). However, if I replace open('/a/large/file').read()
with raw_input() I get EOFError (no errmsg), and even worse, if I replace it
with sys.stdin.read() or even print open('/a/large/file').read() I get IOError:
[Errno 4] Interrupted system call.
I do lots of IO in my work, and primarily with gigantic text files (welcome to
bioinformatics :-). Protecting my code from this sort of error (i believe) will
be quite hard, and probably won't look pretty. Or am I missing something?
Note though that these realtime updates aren't essential to me at the moment.
Basically all I need is to find out for each run how much space I have so I can
text wrap command line help text (as in myprog --help) as user friendly as
possible.
I run Ubuntu 5.10 btw, but I try to stay as cross-platform as I can. My
priorities are Ubuntu, other linuxes, other unixes, Win, Mac.
> Homey don't do Windows, so you'll have to ask somebody else that.
:-)
> I don't know what you mean by "leverage the termios module".
>
>>I have a hunch that we have 100% overlap there,
>
> No comprende.
I mean: I believe that for those environments where $COLS and $ROWS are set
then python will probably have access to the termios module as well, and for
those environments that don't have $COLS and $ROWS set then python probably
will not have access to the termios module either. So, in the latter case I'm
back to square one, which is arbitrary guesswork.
> 1) Just write a normal Unix-like text processing "filter".
Yes that's what I normally do. But I also like to hook them up with a --help
option that shows usage and options and such, and I like that warm fuzzy
feeling you get from seeing really readable user friendly help... :-)
> I would guess that the real answer is that so few people have
> ever wanted it that nobody has ever created a module and
> submitted it. Feel free... ;)
I just might. I've got some stuff that people may benefit from (or possibly
hate, I don't know ;-). If I ever sum up the courage to publish it, would it be
a good idea to post the modules to python-dev@python.org, or is there some
better route?
Thanks again for your time!
/Joel
--
http://mail.python.org/mailman/listinfo/python-list
