Re: signal-USR1-hook woes

[Ed L Cashin]

I would like to run something like the function below on receiving a
SIGUSR1.  It would help me close gnus cleanly on my work machine
before launching a new emacs remotely for using gnus.

  (defun elc-exit-gnus ()
    "go to the group buffer (if it's there) and exit gnus"
    (interactive)
    (save-excursion 
      (let ((g (get-buffer "*Group*"))
            (gnus-interactive-exit nil))
        (if g
           (gnus-group-exit)))))


I went looking for an emacs feature that lets the user associate
actions with SIGUSR1 and SIGUSR2.  The emacs info docs didn't turn up
anything, but I found some old articles using Google groups, including
the one this post is responding to.  (Link provided below.)

  
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=mailman.344.1062998727.18171.help-gnu-emacs%40gnu.org&rnum=3&prev=/groups%3Fq%3Dsignal-USR1-hook%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch


On 08 Sep 2003 08:27:09 +0200 Eli Zaretskii <eliz@elta.co.il> writes:

>> Newsgroups: gnu.emacs.help
>> From: bjdouma@xs2.xs4all.nl (Bauke Jan Douma)
>>      
>>      (message "list-emacs-open-files: done")
>>      (let    (
>>               (buf_list (buffer-list))
>>              )
>
> Yikes!  Why do you insist on formatting Lisp code as if it were C or
> (God forbid) Pascal?  It makes it very hard to read and comprehend.
>
>> Alas, it doesn't work.  It does work from within emacs by
>> calling M-x list-emacs-open-files or by eval'ing
>> (signal-process (emacs-pid) 10).
>> When doing kill -USR1 <emacs-pid>, all that happens is I get a
>> visual bell, the file is not written.
>> An strace reveals that the signal is sent allright.
>> 
>> I am doing something wrong, but what?
>
> Well, is your function at all called?  Does the message you produce at
> the beginning of your function gets inserted into the *Messages*
> buffer?
>
> In other words, the first question you should answer is: is the
> signal delivered to Emacs and handled, but your function has a bug,
> or is the signal itself handled incorrectly by Emacs?
>
> And it will help immensely if you tell what version of Emacs is that
> and on what platform.
>

There is also a gnu.emacs.bug post from Robert Spier on Dec 14, 1997
with the subject "patch for USR1 and USR2 signal handling".  Spier's
patch contains code that shows the hooks being run when emacs receives
a SIGUSR1 or SIGUSR2.  

  
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=199712141954.OAA28984%40blue.seas.upenn.edu&rnum=2&prev=/groups%3Fq%3Dsignal-USR1-hook%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch
  
The code that runs the hooks inside the signal handler is no longer in
src/emacs.c.  That makes sense, from what I know about signal
handlers.  In emacs-21.3, the ChangeLog files show some references to
the feature, it looks like instead of running the user-specified
hooks, an event is created for src/keyboard.c to handle later.
However, the example usage in Spier's patch email no longer works.

Here's my SIGUSR1 handler test case, based on Spier's example:

  (add-hook 'signal-USR1-hook (function
      (lambda ()
        (message "HI!!!"))))

After launching emacs 21.2.1 from debian with "emacs -q" and
evaluating the above code, when a SIGUSR1 is sent to the emacs
process, emacs just beeps.  No message appears in the *Messages*
buffer. 

-- 
--Ed L Cashin     PGP public key: http://noserose.net/e/pgp/