This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mintty: WINCH-signal to child

Thomas Wolff wrote:
Am 19.10.2014 12:11, schrieb Helmut Karlowski:
Am 19.10.2014, 09:48 Uhr, schrieb Duncan Roe:

bash at least has "shopt -s checkwinsize" to achieve what you want,

That would be a workaround for bash. Ideally every process should forward the WINCH-signal to its parent, or the terminal should walk through the call-tree. Both not very likely to happen.

xterm does the same as mintty BTW.
There must be something more about it:
Mined does resend a received SIGWINCH to its parent (as an application should indeed) and it's actually received by bash as can be confirmed with 'trap "echo WINCH" SIGWINCH'. Despite of the received signal bash does not adapt its command line width assumption (as can be checked by typing a long line and seeing where it wraps) (unless that option is enabled).
Probably a bash bug.
Same in mintty as in xterm in all cases.
Same on Linux (bash 3.2.39 on Debian on PowerPC), so not cygwin-specific.
Do you guys also know there was a change between 4.2 and 4.3 in bash's signal handling? In 4.2, bash used to do child processing inside the parent interrupt
which caused problems.  In 4.3, bash waits until a key is pressed before
propagating any signals.

This may be unrelated to whatever problem you are experiencing, but I thought I'd mention you might goog the bash archives on sigwinch and/or winch... (not
sure what would be the exact right invocation, but it may not be related
to what you are experiencing anyway...

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]