Re: SIGWINCH not respected when terminal size is unchanged

Re: SIGWINCH not respected when terminal size is unchanged

[Sheheryar Parvaz]

> Sorry, could you explain exactly what you mean by "not respected" and 
> what breakage you observe? 

If I start an abduco session with zsh running, then disconnect and reconnect from the session, zsh does not redraw the prompt, leaving an empty terminal. If the terminal size is different upon reconnection, then zsh does redraw the prompt.

Abduco relies on programs redrawing when calling SIGWINCH. If they don't, then abduco just shows no output.

SIGWINCH not respected when terminal size is unchanged

[Sheheryar Parvaz]

This breaks software such as abduco and dtach, as they call SIGWINCH upon reattaching.

Re: SIGWINCH not respected when terminal size is unchanged

[Bart Schaefer]

On Thu, Jul 26, 2018 at 6:42 AM, Sheheryar Parvaz <skipper308@hotmail.ca> wrote:
> This breaks software such as abduco and dtach, as they call SIGWINCH upon reattaching.

Sorry, could you explain exactly what you mean by "not respected" and
what breakage you observe?

The signal is certainly always trapped, and zsh always checks that
LINES and COLUMNS match the values returned by TIOCGWINSZ, so the only
internal difference is whether a reset of the line editor occurs.
Other processes are not blocked from receiving the signal.  So what
exactly is wrong?

Re: SIGWINCH not respected when terminal size is unchanged

[Peter Stephenson]

On Thu, 26 Jul 2018 09:03:21 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Thu, Jul 26, 2018 at 6:42 AM, Sheheryar Parvaz
> <skipper308@hotmail.ca> wrote:
> > This breaks software such as abduco and dtach, as they call
> > SIGWINCH upon reattaching.  
> 
> Sorry, could you explain exactly what you mean by "not respected" and
> what breakage you observe?
> 
> The signal is certainly always trapped, and zsh always checks that
> LINES and COLUMNS match the values returned by TIOCGWINSZ, so the only
> internal difference is whether a reset of the line editor occurs.
> Other processes are not blocked from receiving the signal.  So what
> exactly is wrong?

I was going to ask that, but looking at the code I *suspect* that
the line's not being redrawn, which indeed doesn't happen if the
configuration didn't change.  But this needs confirming.

If that's the case, I'm wondering if there's a reason why the code's
like that --- didn't we have to deal with floods of SIGWINCHs causing
havoc at one point?

pws

Re: SIGWINCH not respected when terminal size is unchanged

[Bart Schaefer]

On Thu, Jul 26, 2018 at 9:10 AM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Thu, 26 Jul 2018 09:03:21 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>>
>> Sorry, could you explain exactly what you mean by "not respected" and
>> what breakage you observe?
>
> I was going to ask that, but looking at the code I *suspect* that
> the line's not being redrawn, which indeed doesn't happen if the
> configuration didn't change.  But this needs confirming.

Could the line not being redrawn really be described as having broken
the session manager application?

If that's actually the issue, then it should be work-around-able by
something like

TRAPWINCH() { zle -I }

> If that's the case, I'm wondering if there's a reason why the code's
> like that --- didn't we have to deal with floods of SIGWINCHs causing
> havoc at one point?

Yes, in desktop managers where resizing a window provides live
feedback, the shell will receive a rapid stream of SIGWINCHes as the
user drags the window border around.