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 .
> 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?
(let's leave Emacs aside for now, till we get Most to behave).
> 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:
see my slightly earlier message, if you overlooked it.
> 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".
> 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).
surely at most, Lynx should report eg `Child-process interrupt: continue?',
where `No' would then cause Lynx to exit.
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? i don't find Lynx' current behaviour rational:
is it something which has simply never caused problems before?
--
========================,,============================================
SUPPORT ___________//___, Philip Webb : [EMAIL PROTECTED]
ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto
