From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7783 invoked from network); 6 Oct 1999 17:18:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Oct 1999 17:18:04 -0000 Received: (qmail 20878 invoked by alias); 6 Oct 1999 17:17:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8140 Received: (qmail 20870 invoked from network); 6 Oct 1999 17:17:52 -0000 From: "Bart Schaefer" Message-Id: <991006170433.ZM6609@candle.brasslantern.com> Date: Wed, 6 Oct 1999 17:04:33 +0000 In-Reply-To: <19991005114425.A41016@ichips.intel.com> Comments: In reply to Clint Olsen "3.1.6 issues with command-line wiping" (Oct 5, 11:44am) References: <19991005114425.A41016@ichips.intel.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Clint Olsen , zsh-workers@sunsite.auc.dk Subject: PATCH: 3.0.6/3.1.6: Re: 3.1.6 issues with command-line wiping MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 5, 11:44am, Clint Olsen wrote: } Subject: 3.1.6 issues with command-line wiping } } The symptoms seem to be that if I'm in less, and I resize the window for a } better view of a wide file, ctrl-z-ing back to the shell doesn't seem to } get the lines/columns set properly. This came about somehow in the cumulative procoess-group-handling rewrites that were done over the last few weeks before 3.1.6/3.0.6 were released. The following fixes it for me, but I'm only 95% sure it isn't going to break something else ... I don't *think* it's possible to reach the second hunk with `somestopped' set unless the entire job has been stopped, and I don't know any reason not to set `inforeground' correctly for a suspended job; but I could be wrong about those and I wonder about setting `lastval2' and `lastval'. After this patch, $? is 20 after suspending a job, which disagrees with bash; I don't have a ksh to test against. This means, for example, that less /etc/termcap || echo failed prints "failed" immediately upon hitting ^Z. This could be changed by restoring the `else' and copying the code that sets `inforeground' into the `if (somestopped)' branch (above the first hunk of my patch). I've tested the patch by resizing xterm and then suspending or interrupting during each of less /etc/termcap cat /etc/termcap | while read line; do less; done cat /etc/termcap | while read line; do echo $line; done and it appears to work, but please play with it yourselves and report any oddness. (The patch is against 3.0.6, so expect an offset when patching 3.1.6.) Index: Src/jobs.c =================================================================== @@ -236,7 +236,8 @@ } return; } - } else { /* job is done, so remember return value */ + } + { /* job is done or stopped, remember return value */ lastval2 = val; /* If last process was run in the current shell, keep old status * and let it handle its own traps, but always allow the test @@ -261,7 +262,7 @@ if (mypgrp != pgrp && inforeground && (jn->gleader == pgrp || (pgrp > 1 && kill(-pgrp, 0) == -1))) { if (list_pipe) { - if (pgrp > 1 && kill(-pgrp, 0) == -1) { + if (somestopped || (pgrp > 1 && kill(-pgrp, 0) == -1)) { attachtty(mypgrp); /* check window size and adjust if necessary */ adjustwinsize(0); -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com