gnuclient messes up tty
HASM
Starting with some update a few months back, not sure if a Fedora
11 update or xemacs update, but most likely some kernel update,
my tty gnuclient gets messed up in a strange way.
I'm now on fedora 12/gdm login/user script/fvwm. Fvwm starts
xemacs automatically. That xemacs and any other that I start
from fvwm's menu will mess up tty gnuclient's sessions.
Here's a simply receipe.
- Change fvwm config to start "xemacs -vanilla".
- Start xemacs from fvwm's menu
- In xemacs
(load-file "/path/to/gnuserv.el")
(set-variable 'debug-on-error t)
(gnuserv-start)
- Start a xterm from fvwm's menu
- In xterm
gnuclient -nw
Xemacs will complain in the minibuffer
wrong-type-argument stringp nil
and, as soon as I type anything to in xterm, I'm returned to the
prompt and the tty is messed up.
Now, if I do this instead:
- Start xterm from fvwm's menu
- In that xterm
xemacs 1>/dev/null 2>&1 &; disown
# wait for (full user inited) xemacs to come up
gnuclient -nw
This gnuclient session works fine, which seems to point at
something on fvwm's environment, lack of tty, or something like
that.
The debug backtrace is (replaced the literal control-d with C-d):
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
signal(wrong-type-argument (stringp nil))
(condition-case oops (eval (car ...)) (error (setq gnuserv-string "") (when gnuserv-current-client ...) (setq gnuserv-current-client nil) (signal ... ...)) (quit (setq gnuserv-string "") (when gnuserv-current-client ...) (setq gnuserv-current-client nil) (signal ... nil)))
(let ((header ...)) (setq gnuserv-current-client (car header)) (condition-case oops (eval ...) (error ... ... ... ...) (quit ... ... ... ...)) (setq gnuserv-string ""))
(cond ((string-match "\\`[0-9]+" gnuserv-string) (let ... ... ... ...)) (t (let ... ... ...)))
(if (string-match "C-d\n?\\'" gnuserv-string) (cond (... ...) (t ...)))
(when (string-match "C-d\n?\\'" gnuserv-string) (cond (... ...) (t ...)))
gnuserv-process-filter(#<process "gnuserv" pid 5044 state:run> "4 (gnuserv-edit-files '(tty \"/dev/pts/5\" \"xterm\" 5109) '())C-d")
My Emacs-Lisp or Lisp in general is below par. Seems it is
generates an error eval'ing this
(gnuserv-edit-files '(tty \"/dev/pts/5\" \"xterm\" 5109) '())
but can't determine at which point if fails in there.
Version info:
"XEmacs 21.5 (beta29) \"garbanzo\" [Lucid] (i386-redhat-linux, Mule) of Mon Nov 9 2009 on xenbuilder4.fedora.phx.redhat.com"
;;; gnuserv.el --- Lisp interface code between Emacs and gnuserv
;; Copyright (C) 1989-1997 Free Software Foundation, Inc.
;; Version: 3.12
Linux my.domain.com 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 athlon i386 GNU/Linux
des...@verizon.net
> Starting with some update a few months back, not sure if a Fedora
> 11 update or xemacs update, but most likely some kernel update,
> my tty gnuclient gets messed up in a strange way.
>
> I'm now on fedora 12/gdm login/user script/fvwm. Fvwm starts
> xemacs automatically. That xemacs and any other that I start
> from fvwm's menu will mess up tty gnuclient's sessions.
>
> Here's a simply receipe.
> - Change fvwm config to start "xemacs -vanilla".
> - Start xemacs from fvwm's menu
> - In xemacs
> (load-file "/path/to/gnuserv.el")
> (set-variable 'debug-on-error t)
> (gnuserv-start)
> - Start a xterm from fvwm's menu
> - In xterm
> gnuclient -nw
I'm not sure...
That load file looks suspicious. I never had to use it.
Are you sure the path is right?
You should be able to just do the gnuserv-start.
For starting gnuserv, this is what I use:
(defun gnuserv-start-with-sentinel ()
"Starts gnuserv. If running under X, when gnuserv dies notify the user."
(interactive)
(if (and (gnuserv-start) (eq (device-type) 'x))
(set-process-sentinel server-process
(lambda (process event)
(gnuserv-start-with-sentinel)))))
(if (string-equal (exec-to-string
(format "ps -u %s | grep gnuserv" (user-uid))) "")
(gnuserv-start-with-sentinel))
))
Most of the above is for multi-user systems and to avoid trying to start
2 gnuservs or starting one from a TTY.
But at no point do I load anything using a full path.
HASM
>> (load-file "/path/to/gnuserv.el")
> I'm not sure...
> That load file looks suspicious. I never had to use it.
> Are you sure the path is right?
> But at no point do I load anything using a full path.
The point of loading the .el file is to make the debug backtrace have some
meaningful info, otherwise when you do (gnuserv-start) it is picked up from
the corresponding .elc and the debug backtrace may not have all the info
one needs, e.g. akin to loading the source of a program in gdb.
If you do (describe-function 'gnuserv-start) it replies with:
`gnuserv-start' is an interactive compiled Lisp function
-- loaded from "gnuserv"
thus you will need to load the first gnuserv.el on your load-path.
-- HASM
des...@verizon.net
The second example isn't clear.
In the second case did you start the gnuclient from the same xterm
that you launched xemacs from?
In the Fvwm config files, what command are you using to launch
xemacs and the xterm.
I believe you should use "Exec exec".
HASM
>> - In that xterm
>> xemacs 1>/dev/null 2>&1 &; disown
>> # wait for (full user inited) xemacs to come up
>> gnuclient -nw
> The second example isn't clear. In the second case did you start the
> gnuclient from the same xterm that you launched xemacs from?
Yes, (That's why all those lines were indented under the xterm line...
> In the Fvwm config files, what command are you using to launch xemacs and
> the xterm. I believe you should use "Exec exec".
Yes, that's how xemacs is started in my config file.
But the error I get is from xemacs/gnuclient getting something wrong.
-- HASM