10:36 p.m.
>>>> "Mike" == Mike Kupfer
<mike.kupfer(a)sun.com> writes:
Mike> What's more confusing is that I'm suddenly having problems getting
Mike> "gnuclient -nw" to start up at all. When I run it, instead of
Mike> getting an XEmacs frame, it hangs. If I C-z it, I get
Mike> ^Z[2] + Stopped (SIGTSTP) /usr/local/bin/gnuclient -nw [1] -
Mike> Stopped (SIGTTOU) xemacs &
Mike> Putting job 1 (xemacs) into the foreground gives me my tty frame.
Mike> But then I can't get out with C-x 5 0. The tty frame is cleared,
Mike> but I don't get my shell back.
Mike> This is on Solaris, a recent development build of 5.11, using ksh
Mike> as my shell.
I can reproduce this on Linux.
It appears to result from running "gnuclient -nw" from the same shell
that I started XEmacs in. If I run "gnuclient -nw" from a different
shell, things work normally. Want me to file a formal bug report (M-x
report-xemacs-bug)?
mike
1:38 a.m.
Mike Kupfer writes:
>>>>> "Mike" == Mike Kupfer
<mike.kupfer(a)sun.com> writes:
Mike> Putting job 1 (xemacs) into the foreground gives me my tty
frame.
Mike> But then I can't get out with C-x 5 0. The tty frame is cleared,
Mike> but I don't get my shell back.
Mike> This is on Solaris, a recent development build of 5.11, using ksh
Mike> as my shell.
I can reproduce this on Linux.
It appears to result from running "gnuclient -nw" from the same shell
that I started XEmacs in. If I run "gnuclient -nw" from a different
shell, things work normally. Want me to file a formal bug report (M-x
report-xemacs-bug)?
You can if you wish, but I think this is clear enough. If you come up
with more information, please do file a formal bug report then.
Steve
10:27 a.m.
Ar an seachtú lá déag de mí Lúnasa, scríobh Mike Kupfer:
It appears to result from running "gnuclient -nw" from the
same shell
that I started XEmacs in. If I run "gnuclient -nw" from a different
shell, things work normally. Want me to file a formal bug report (M-x
report-xemacs-bug)?
No, I can reproduce. There’s some logic related to TTYs and controlling
processes here that I need to understand some more before I can fix this,
though. Workaround; don’t start TTY gnuclients from the same shell you
started a window system XEmacs.
--
Santa Maradona, priez pour moi!
2:37 p.m.
On Fri, 18 Aug 2006, Aidan Kehoe wrote:
Ar an seachtú lá déag de mí Lúnasa, scríobh Mike Kupfer:
> It appears to result from running "gnuclient -nw" from the same shell
> that I started XEmacs in. If I run "gnuclient -nw" from a different
> shell, things work normally. Want me to file a formal bug report (M-x
> report-xemacs-bug)?
No, I can reproduce. There's some logic related to TTYs and controlling
processes here that I need to understand some more before I can fix this,
though. Workaround; don't start TTY gnuclients from the same shell you
started a window system XEmacs.
I have some more odd behaviour regarding gnuclient -nw:
Start xemacs from a random tty.
Start gnuclient -nw from another shell. Works fine. Can ctrl-z out of
there, and fg back in.
But fork gnuclient -nw from another program (eg, crontab -e), via
$EDITOR=a shell script, and ctrl-z now just waits indefinitely until I
killall -CONT gnuclient.
Sometimes, related to this (circumstances I can't recall, but may try to
reproduce if you can't reproduce), gnuclient will keep on updating the
screen, I think there have been conditions where both the shell and xemacs
fight for and get the keyboard input randomly.
Does anyone else see this?
--
Tim Connors
9:50 a.m.
Ar an chéad lá is fiche de mí Lúnasa, scríobh Tim Connors:
> > It appears to result from running "gnuclient
-nw" from the same shell
> > that I started XEmacs in. If I run "gnuclient -nw" from a
different
> > shell, things work normally. Want me to file a formal bug report (M-x
> > report-xemacs-bug)?
>
> No, I can reproduce. There's some logic related to TTYs and controlling
> processes here that I need to understand some more before I can fix this,
> though. Workaround; don't start TTY gnuclients from the same shell you
> started a window system XEmacs.
I have some more odd behaviour regarding gnuclient -nw:
Start xemacs from a random tty.
Start gnuclient -nw from another shell. Works fine. Can ctrl-z out of
there, and fg back in.
But fork gnuclient -nw from another program (eg, crontab -e), via
$EDITOR=a shell script, and ctrl-z now just waits indefinitely until I
killall -CONT gnuclient.
Sometimes, related to this (circumstances I can't recall, but may try to
reproduce if you can't reproduce), gnuclient will keep on updating the
screen, I think there have been conditions where both the shell and xemacs
fight for and get the keyboard input randomly.
Does anyone else see this?
I see the crontab behaviour; looks like there are a lot of quirks of
gnuclient’s interaction with process groups that need to be worked out. (I
don’t think McKusick, Joy and the rest had gnuclient and XEmacs or anything
like them in mind mind when they came up with the idea first.)
I haven’t seen the keep-updating-the-screen behaviour. I do occasionally see
a broken reaction to terminal size changes; gnuclient will think the
terminal two or three characters by two or three characters, and the only
way to get a usable frame is to C-x 5 0 then call gnuclient again.
--
Santa Maradona, priez pour moi!
6451
days inactive
6456
days old
4 comments
4 participants
participants (4)
-
Aidan Kehoe -
Mike Kupfer -
Stephen J. Turnbull -
Tim Connors