A command ran from emacs receives a "signal 1" while it does not when run in a shell

A command ran from emacs receives a "signal 1" while it does not when run in a shell

[François Fleuret]

Hi,

I am trying to write an elisp application to control vlc, the
multi-media player and I have a weird bug.

Vlc can be run in such a mode that it gets commands in stdin and send
results in stdout. If ran from a bash shell (in an xterm), I can for
instance send it "add file://toto.mp3\n" and it will play the given
mp3, if I send "stop\n", it will stop playing and wait for more
commands.

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".

Did I miss something here?

-- 
François Fleuret

Re: A command ran from emacs receives a "signal 1" while it does not when run in a shell

[François Fleuret]

Hi,

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 ?

Cheers,

-- 
François Fleuret

Re: A command ran from emacs receives a "signal 1" while it does not when run in a shell

[Daniel Pittman]

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

Re: A command ran from emacs receives a "signal 1" while it does not when run in a shell

[François Fleuret]

Hi,

> 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.

I do not get it. vlc stops, pretending to get a SIGHUP, while the
wrapper does not, altough it would die if I kill -HUP it from a shell
...

That's weird.

-- 
François Fleuret                              EPFL - CVLAB/LCN