[ resending this message - first copy apparently got lost ]
---------- Forwarded message ----------
Date: Tue, 14 Mar 2000 16:44:50 -0600 (CST)
From: Klaus Weide <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: lynx-dev ^g is a menace
On Thu, 2 Mar 2000, Philip Webb wrote:
> PS to my longer message today, the introduction of ^g seems to occur
> only when my editor & Most are called as daughters: cp diffs:
[snipped to most relevant lines:]
>
> (5) Edit at UNIX prompt vs Edit from Lynx Print screen
>
> < intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^A; eol = ^@; old-swtch = ^@;
>susp = ^@
> ---
> > intr = ^G; quit = ^G; erase = ^H; kill = ^U; eof = ^A; eol = ^@; old-swtch
><undef>; susp <undef>
> (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 = ^@
This is very strange. Why would those progs *not* set 'intr = ^G' in some
situations? I have no explanation, but the answer may be hidden somewhere
in the slang source.
I assume that both your editor and most are using slang; is that
correct? Setting 'intr = ^G' seems to be a slang thing. I get this
with 'most' (which is linked against libslang), but I get it whether
starting most from the shell or from lynx. GNU Emacs (in text mode)
does the same thing.
In UNIX, every user process is a child - the commands you type at
the shell prompt start processes that are children of the shell
process. So maybe you would get different output wrt. 'intr' if
you try different shells (sh, bash, (t)csh, ... - as well as
differences whether 'set -o emacs' is in effect or not in ksh or
similar shells).
All this is becoming more tangential - it should be ok for any program
to set 'intr' as it likes (whether it makes sense is another question),
and the parent process should be isolated from suffering the unwanted
consequences, by being isolated from it through the usual system()
behavior.
Where to go from here? 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, and whether there is a known workaround (say, some
compiler option or compatibility library).
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.
Lynx could include its own system() implementation that doesn't have
this problem. That doesn't look very attractive either.
Klaus
