On 2006-02-06, Joel Hedlund <[EMAIL PROTECTED]> wrote: > 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()
A stylistic point: In almost all Python programs, uppercase identifiers are almost always reserved for constants (as in C). The language itself doesn't care, of course. > 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 Hmm. There things you're not allowed to do in a signal handler. I don't know if the TIOCGWINSZ ioctl() is one of them or not. If it's not allowed, then what one usually does is set a flag in the signal handler then check the flag in your main loop and do the ioctl() there. > 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!). I wouldn't be surprised if Python catches that exception and restarts the I/O operation. > 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. Yup, that's the exception. Standard practice is to catch it and retry the I/O operation. > 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? You might want to try just setting a flag in the signal handler to see if that prevents the I/O operations on stdin/stdout from being interrupted. > 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. It sounds like getting the terminal width once at the start of the program is probably good enough. That's what a lot of text-mode programs that aren't doing a log of fancy full-screen stuff do. > 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. Yes, that's probably true. In that case, most people assume 80x24. > 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? I think what most people do initially is to put the module somewhere publically accessible and post an announcement to c.l.p and c.l.p.a. If you feel particularly ambitious you could create a project for it on sourceforge or somewhere like that. I don't know what the procedure is for nominating a module for inclusion in the standard library. -- Grant Edwards grante Yow! YOW!! Now I at understand advanced visi.com MICROBIOLOGY and th' new TAX REFORM laws!! -- http://mail.python.org/mailman/listinfo/python-list