On Tue, 29 Feb 2000, Philip Webb wrote:
> 000229 Klaus Weide wrote:
> > On Mon, 28 Feb 2000, Philip Webb wrote:
> >> only after invoking Most or my editor from the Print screen
> >> or my editor from the g e-mail screen
> >> or after Mutt (from the Print screen) invokes my editor;
> >> not from the Print screen itself or a normal Lynx screen;
> > obviously invoking those external programs has some lasting effect
> > that it shouldn't have.
>
> not only not obvious, no even so (smile)!
> there's no difference in behaviour at the normal Lynx pseudo-prompt
> before/after invoking the external programs;
> the problem arises ONLY WHILE USING those programs.
Then (obviously) I misunderstood your description.
(My other message takes account of that.)
> > It could be (a) lynx's fault, (b) curses's fault,
> > (c) the external programs' fault, or some combination.
>
> yes: i'ld say (a), in that Lynx is taking an internal program command
> as an overriding command to Lynx itself or to the system.
I'd say now it's the fault of the system() which was compiled into
lynx (or with which lynx is linked). In combination with a certain
behavior of the external program, which by itself should not be
harmful (or, at least, should not terminate lynx).
> > What happens if you set your "editor" to smoething simple like cat
> > then try to 'edit' a file (in a new lynx session)?
In light of improved understanding what the problem is, playing around
with 'cat' doesn't make much sense any more. But you might try 'more',
and kill the 'more' with ^C. I expect this will also terminate lynx
(which it shouldn't).
> to make this work you have to invoke cat alone,
> which tries to take input from Stdin: Lynx sits there "printing file",
> & entering ^g simply echoes it as ^G on the screen;
> entering ^c to exit cat also exits Lynx,
> which also happens if i enter ^c at the Lynx pseudo-prompt.
> BTW how do you terminate Stdin input for cat without using ^c ?
Normally ^D, or whatever 'stty -a' shows as 'eof = '.
> >> if i enter ^g after starting Mutt from the Print screen,
> >> but before Mutt calls the editor, the print request is cancelled.
Is that how mutt, on its own, is supposed to react to ^g?
> > Let's try to find out what it is while Lynx is in curses mode.
> > --- script & instructions snipped ---
> > Compare output between the normal state (before calling any editor etc)
> > and the lynx-aborts-on-^g state.
>
> ... there's no difference (as one would expect: see above).
> however, there ARE differences from stty -a outside Lynx:
Thanks for checking. Yes, those difference are expected.
You are comparing the "normal" or "shell mode" set of settings
with the "curses mode" settings. Using a lynxcgi is just at trick
to get at the latter, without using a form of command that would
switch *out of* "curses mode" first and would thereby make the
exercise pointless. (Think quantum-mechanics measurements...)
But, since you are using screen, there's a different way to observe
the current state of one program's tty settings, without modifying
the observables. This should work for all programs, not just while
lynx has control. You should be able to verify that, while 'mutt'
is in control, 'intr = ^G' is in effect:
1. Open two screen sessions.
In the first you will run lynx (and/or mutt).
The second is for looking at the first's state.
2. Switch to #1. Run the command
tty
It will show something like
/dev/ttya0
Make a note of it.
3. Now run lynx in #1.
4. Switch to #2. Execute the command
stty -a < /dev/ttya0
(Replace ttya0 with whatever you got in step 2.)
5. Do various things in #1, like invoking mutt, and repeat 4. for
looking at #1's tty settings in effect at that point.
Yuu should be able to find out which commands do/don't set intr = ^G.
Klaus
