Andres Freund <andres@anarazel.de> writes:
> On 2015-12-16 12:23:28 -0500, Tom Lane wrote:
>> It may be that we can't fix this in readline versions that precede the
>> introduction of the resize function. Let me go experiment on my pet
>> dinosaurs.
> I'm not particularly bothered by not supporting old readline versions
> here.
I'm not either, just wanted to know if it was possible. (Answer: no.
rl_resize_terminal definitely does not do what we want, neither in
current releases nor in 4.2. It looks to me like it's only intended
to be called while interactive input is active, which is the only
time that libreadline has its signal handler in place.)
> If we really want to we could basically directly use
> _rl_get_screen_size() - which seems to have been present from before
> 4.0. It's not declared static...
Nah, I don't think we should rely on calling undocumented internal
readline functions. We've lived with this behavior for long enough
that I don't think it's a catastrophe if we don't fix it for ancient
readline releases.
One issue I do have with the patch as proposed is that it will call
rl_reset_screen_size even with -n, which does not seem like a good
idea. There's no guarantee that rl_reset_screen_size will behave
nicely if libreadline hasn't been initialized properly, and even
if it does, it will have side-effects on the LINES/COLUMNS environment
variables which are potentially user-visible and should not happen
with -n. I think the most reasonable way to handle this is to put the
call into a new function exported from input.c, where it can be
made conditional on useReadline.
Except for that minor rearrangement, I think this is a good patch
and we should accept it. Does anyone object to back-patching it?
regards, tom lane