From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Clint Olsen <olsenc@ichips.intel.com>, zsh-workers@sunsite.auc.dk
Subject: PATCH: 3.0.6/3.1.6: Re: 3.1.6 issues with command-line wiping
Date: Wed, 6 Oct 1999 17:04:33 +0000 [thread overview]
Message-ID: <991006170433.ZM6609@candle.brasslantern.com> (raw)
In-Reply-To: <19991005114425.A41016@ichips.intel.com>
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
prev parent reply other threads:[~1999-10-06 17:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-05 18:44 Clint Olsen
1999-10-06 17:04 ` Bart Schaefer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=991006170433.ZM6609@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=olsenc@ichips.intel.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).