Gregory Stark <stark@enterprisedb.com> writes:
> Could you define "messed up"?
>
> What I see is that the query output is formatted correctly but readline still
> thinks the screen is the old size. (This is in CVS HEAD -- this code was
> definitely different in 8.3 and before so the behaviour may be different).
>
> Perhaps we need to tell readline whenever we run a subprocess and it may have
> missed screen resize signals.
Hm, this Bash FAQ seems to indicate this shouldn't be a problem -- the whole
process group is supposed to get the window size. Psql isn't doing the job
control stuff the FAQ entry talks about so the pager ought to be in the same
process group. So I'm puzzled.
http://tiswww.case.edu/php/chet/bash/FAQ
-> E11) If I resize my xterm while another program is running, why doesn't bash
-> notice the change?
->
-> This is another issue that deals with job control.
->
-> The kernel maintains a notion of a current terminal process group. Members
-> of this process group (processes whose process group ID is equal to the
-> current terminal process group ID) receive terminal-generated signals like
-> SIGWINCH. (For more details, see the JOB CONTROL section of the bash
-> man page.)
->
-> If a terminal is resized, the kernel sends SIGWINCH to each member of
-> the terminal's current process group (the `foreground' process group).
->
-> When bash is running with job control enabled, each pipeline (which may be
-> a single command) is run in its own process group, different from bash's
-> process group. This foreground process group receives the SIGWINCH; bash
-> does not. Bash has no way of knowing that the terminal has been resized.
->
-> There is a `checkwinsize' option, settable with the `shopt' builtin, that
-> will cause bash to check the window size and adjust its idea of the
-> terminal's dimensions each time a process stops or exits and returns control
-> of the terminal to bash. Enable it with `shopt -s checkwinsize'.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
