On Thu, 16 Mar 2000, Philip Webb wrote:
> 000316 Klaus Weide wrote:
> > [ resending this message - first copy apparently got lost ]
>
> yes, there's been some problem at sig.net this week:
> there was an empty message from BI (see Archive)
> & messages have an extra header `X-warning-authorisation' or something.
>
> > On Thu, 2 Mar 2000, Philip Webb wrote:
>
> thanx for keeping up with messages: it is appreciated.
>
> >> introduction of ^g seems to occur
> >> only when my editor & Most are called as daughters: cp diffs:
> >> (6) Most at UNIX prompt vs Most from Lynx Print screen
> >> < intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^A; eol = ^@; old-swtch =
>^@; susp = ^@
> >> ---
> >> > intr = ^G; quit = ^@; erase = ^H; kill = ^U; eof = ^A; eol = ^@; old-swtch =
>^@; susp = ^@
>
> let's stick to Most, as we both use it.
>
> > This is very strange.
>
> yes ...
>
> > I assume your editor & Most are using slang; is that correct?
>
> Most has to use Slang; the editor is a local version of Emacs.
> my Lynx, however, is compiled with Curses (not Ncurses).
>
> > Setting intr = ^G seems to be a Slang thing.
> > I get this with Most (which is linked against libslang),
> > whether starting from the shell or from Lynx.
> > GNU Emacs (in text mode) does the same thing.
> > Why would those progs *not* set intr = ^G in some situations?
> > the answer may be hidden somewhere in the Slang source.
>
> so one possibility is to hack Slang to avoid so setting ^g .
Yes, but it would be only a workaround.
The reason why many (most?) slang applications do this, even those
that aren't really interested in having ^G produce SIGINT, is
the function SLang_init_tty (and/or its documentation for programmers).
The slang docs have examples like this:
if (-1 == SLang_init_tty (7, 0, 0)) /* For MSDOS, use 34 as scan code */
The first parameter is described as specifying "the interrupt character
(SIGINT)". (7 stands for ^G.) It isn't made clear (or not clear enough)
that ^G can still act as an abort character to cancel *text input* even if
it is not used as "interrupt character". So I guess many programmers using
the slang library just copy from that example.
Here's what lynx itself does instead:
#if SLANG_VERSION > 9929
SLang_init_tty(-1, 0, 1);
#else
SLang_init_tty(3, 0, 1);
#endif /* SLANG_VERSION > 9929 */
The -1 stands for "leave it alone, whatever it is". Slang versions before
0.99.30 apparently didn't support this, so for earlyier versions lynx
just uses 3 aka ^C explicitly.
> > In UNIX, every user process is a child,
> > so maybe you would get different output wrt intr
> > if you try different shells: sh bash (t)csh ,
> > & whether set -o emacs is in effect in ksh or similar shells.
>
> so how do i tell the Lynx shell which shell to use for its children?
I'm not sure what you mean with "Lynx shell".
But what I meant was, for examples, (assuming you normally use tcsh)
[tcsh prompt]$ bash
[bash's prompt]$ lynx ...
or
[tcsh prompt]$ ksh
[ksh's prompt]$ set -o emacs # or not, or set -o vi
[ksh's prompt]$ lynx ...
> (let's leave Emacs aside for now, till we get Most to behave).
I meant "emacs" mode as one of several possible line-editing modes of a
shell, as shown above for ksh.
> > it should be ok for any program to set intr as it likes
> > & the parent should be isolated from suffering the unwanted consequences
> > by being isolated from it through the usual system() behavior.
>
> the other half of the problem is that system() doesn't behave itself here:
The system() is the only party whose behavior is clearly wrong, IMO.
> see my slightly earlier message, if you overlooked it.
[ not sure which one - did it get lost? ]
> > So far, this seems to be a problem specific to your OS.
> > You could check whether this is a common known problem with its libraries
> > & whether there is a known workaround,
> > say some compiler option or compatibility library.
>
> the system is managed by competent, but overworked & distant, sysadmins,
> who rarely get asked about anything as technical as this.
> if they respond at all, it's likely to be:
> "We didn't realise anyone was still using Lynx".
But there should be newsgroups, an FAQ, web pages specific to IRIX / SGI
problems. (if I remember the OS right)
> > Lynx could bracket each system() call with a command to ignore
> > and restore SIGINT. That would probably lead to undesirable behavior
> > in some child processes, so it shouldn't be done in general.
>
> is there any reason why Lynx should treat the SIGINT from its daughters
> as an instruction to itself to exit? to me, this seems stupid (smile).
A signal doesn't "come from" another (here: daughter) process, it comes
from the kernel. Of course, some other process may have done something
to cause the kernel to send it, but the recipient of the signal doesn't
know anything about that.
In our case, the tty driver (or similar part of the kernel) generates
SIGINT, for one or more processes connected to the tty device, when ^G
is pressed. It is reacting in this way to ^G because ^G is set as the intr
character. But it has long been forgotten who set up the tty this way,
daughter or granddaughter or lynx or its parent shell or...
> surely at most, Lynx should report eg `Child-process interrupt: continue?',
> where `No' would then cause Lynx to exit.
Lynx should never *get* the interrupt in the first place.
> if there might be problems with some systems,
> could that not be made an option in lynx.cfg ?
>
> > Lynx could include its own system() implementation
> > that doesn't have this problem. That doesn't look very attractive either.
>
> why not?
Because the only known benefit (so far) is to work around *one*
system's system() problems? Because Lynx seems to work well enough
with all other systems' system()s?
> i don't find Lynx' current behaviour rational:
> is it something which has simply never caused problems before?
Maybe there aren't many systems where system() behaves this "irrationally",
or not many poeple are using Lynx on IRIX, or using Lynx *and* slang programs
as daughters, or it's limited to a specific OS version, or...
But other users of your OS may have better answers than I! (see newsgroups..)
Klaus
