resize timeout handling / grabbing size from stderr doubt

[Denis Vlasenko]

On Wednesday 14 March 2007 09:13, Bernhard Fischer wrote:
> >I must admit that I didn't know that new.c_cc[VTIME] exists,
> >let alone what does it mean.
> 
> It's the timeout for a write.
> I don't know how i would be able to reproduce such a write-error?

We need to guard against _read_ timeout here
(when terminal doesn't return encoded sequence with [height, width])
This is easy to reproduce. redirect relevant descriptor to non-terminal:

# sleep 100 | resize
<<< waits 100 seconds >>>
COLUMNS=0;LINES=0;export COLUMNS LINES;

> Re: your change to use stderr to grab the winsize.
> Is the winsize guaranteed to be equal for stdout and stderr for a given
> process?

No.

> What about this scenario:
> stdout/stdin comes from /dev/fb0 which is 80x24 and stderr is redirected
> to /dev/fb1 which is (random numbers) 123x96 ?
> 
> Will svn with your recent change to use stderr correctly output 80x24 or
> the incorrect 123x96 ?

Why do you think that stdout is the descriptor pointing to
tty we want to measure? Think about it - why resize
are trying to print result in shell-like format?
Because it is meant to be also usable in backticks:

r=`resize`
...
eval $r

But when you run stuff in backticks, stdout *is redirected*
to internal shell pipe! If we want resize to work in backticks,
we *must not* try to measure tty attached to stdout.

This leaves us with two possibilities:
a) write esc sequences to *stderr*, read response from stdin.
b) open "/dev/tty" do both writes and reads on it.
--
vda