Best way of finding terminal width/height?

[Grant Edwards]

On 2006-02-06, Joel Hedlund <joel.hedlund at gmail.com> 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 at 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!!