[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A command ran from emacs receives a "signal 1" while it does not whe
From: |
Daniel Pittman |
Subject: |
Re: A command ran from emacs receives a "signal 1" while it does not when run in a shell |
Date: |
Mon, 27 Sep 2004 23:09:11 +1000 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) |
On 27 Sep 2004, François Fleuret wrote:
> François Fleuret wrote on 25 Sep 2004 22:58:05 MET:
>
>> If I set up a process in emacs with start-process,
>> set-process-filter and set-process-sentinel, and send the first
>> string with process-send-string, it will play the mp3. But if I send
>> the second string, it will stop and then it will tells me (in its
>> stdout) "signal 1 received" and dies. The sentinel in emacs will get
>> "finished".
>
> If I invoke vlc through a wrapper shell-script of the form
>
> ,------------------
> | #!/bin/bash
> | vlc --intf rc
> `------------------
>
> there is no problem anymore. I do not understand a lot to the UNIX
> signal handling thing, but is it possible that emacs sends a signal 1
> to the invoked executable ?
Signal 1 is 'HUP' under Linux, at least, and under most Unix systems as
I recall. That is sent when the controlling terminal of an application
is closed.
If Emacs uses a pty to talk to the vlc instance, and that was closed
at some point, that would generate a SIGHUP to the application.
Using the shell presumably insulates from that in some fashion.
xine should probably not die when the controlling terminal is closed.
Daniel
--
The true way to overcome the evil of class distinctions is not to
denounce them as revolutionists denounce them, but to ignore them as
children ignore them.
-- Charles Dickens