Re: Process sentinel not called in batch mode

Re: Process sentinel not called in batch mode

[Chong Yidong]

Helmut Eller <eller.helmut@gmail.com> wrote:

> process-sentinels aren't called in batch mode.  I'm not sure if this
> is a bug or the expected behavior, but I find this quite frustrating.
> To reproduce the problem do:
> $shell> cat test-sentinel.el

  (defvar sentinel-called nil)
  (defun main ()
    (let ((proc (start-process "test" nil "bash" "-c" "sleep 1 ; exit 20")))
      (set-process-sentinel proc (lambda (proc msg)
                                 (message "sentinel: %S %s" proc msg)
                                 (setq sentinel-called t)))
    (while (not sentinel-called)
      (message "status: %s exit-status: %s sentinel-called: %s" 
               (process-status proc) (process-exit-status proc) 
               sentinel-called)
      (sit-for 1)
      (accept-process-output proc 1))))
  (main)

> $shell> emacs -Q -batch -l test-sentinel.el

This problem occurs because wait_reading_process_output only calls
status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
Although wait_reading_process_output is called from many places in
Emacs, it is given a nonzero DO_DISPLAY argument only during
kbd_buffer_get_event.  But that function is never called in batch mode.

Maybe something like the attached patch should be applied.
Alternatively, we could change Faccept_process_output so that when Emacs
is in batch mode, it calls wait_reading_process_output with a nonzero
DO_DISPLAY argument.  Opinions?

*** trunk/src/process.c.~1.539.~	2008-04-09 13:46:04.000000000 -0400
--- trunk/src/process.c	2008-05-13 19:27:01.000000000 -0400
***************
*** 4414,4420 ****
  	 available, notify the user of the change right away.  After
  	 this explicit check, we'll let the SIGCHLD handler zap
  	 timeout to get our attention.  */
!       if (update_tick != process_tick && do_display)
  	{
  	  SELECT_TYPE Atemp;
  #ifdef NON_BLOCKING_CONNECT
--- 4414,4421 ----
  	 available, notify the user of the change right away.  After
  	 this explicit check, we'll let the SIGCHLD handler zap
  	 timeout to get our attention.  */
!       if (update_tick != process_tick
! 	  && (do_display || noninteractive))
  	{
  	  SELECT_TYPE Atemp;
  #ifdef NON_BLOCKING_CONNECT

bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

> This problem occurs because wait_reading_process_output only calls
> status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
> Although wait_reading_process_output is called from many places in
> Emacs, it is given a nonzero DO_DISPLAY argument only during
> kbd_buffer_get_event.  But that function is never called in batch mode.

Does anyone know why we test do_display there?


        Stefan

Re: Process sentinel not called in batch mode

[Stefan Monnier]

> This problem occurs because wait_reading_process_output only calls
> status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
> Although wait_reading_process_output is called from many places in
> Emacs, it is given a nonzero DO_DISPLAY argument only during
> kbd_buffer_get_event.  But that function is never called in batch mode.

Does anyone know why we test do_display there?


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Richard M Stallman]

    > This problem occurs because wait_reading_process_output only calls
    > status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
    > Although wait_reading_process_output is called from many places in
    > Emacs, it is given a nonzero DO_DISPLAY argument only during
    > kbd_buffer_get_event.  But that function is never called in batch mode.

    Does anyone know why we test do_display there?

I think the idea is, if you are going to update the display, it is
good to display the fact that a process has terminated.

I don't claim this implies the code should not be changed.

Re: bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

>> This problem occurs because wait_reading_process_output only calls
>> status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
>> Although wait_reading_process_output is called from many places in
>> Emacs, it is given a nonzero DO_DISPLAY argument only during
>> kbd_buffer_get_event.  But that function is never called in batch mode.

>     Does anyone know why we test do_display there?

> I think the idea is, if you are going to update the display, it is
> good to display the fact that a process has terminated.

This side I understand, but what about the other: why should we not
check process status in the case where we are not redisplaying?


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 16 May 2008 09:25:54 -0400
> Cc: 141@emacsbugs.donarmstrong.com, cyd@stupidchicken.com,
> 	eller.helmut@gmail.com, emacs-devel@gnu.org,
> 	bug-submit-list@donarmstrong.com, bug-gnu-emacs@gnu.org
> 
> >> This problem occurs because wait_reading_process_output only calls
> >> status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
> >> Although wait_reading_process_output is called from many places in
> >> Emacs, it is given a nonzero DO_DISPLAY argument only during
> >> kbd_buffer_get_event.  But that function is never called in batch mode.
> 
> >     Does anyone know why we test do_display there?
> 
> > I think the idea is, if you are going to update the display, it is
> > good to display the fact that a process has terminated.
> 
> This side I understand, but what about the other: why should we not
> check process status in the case where we are not redisplaying?

Because Emacs generally looks at process output only when it's idle?

Re: bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

>> >> This problem occurs because wait_reading_process_output only calls
>> >> status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
>> >> Although wait_reading_process_output is called from many places in
>> >> Emacs, it is given a nonzero DO_DISPLAY argument only during
>> >> kbd_buffer_get_event.  But that function is never called in batch mode.
>> 
>> >     Does anyone know why we test do_display there?
>> 
>> > I think the idea is, if you are going to update the display, it is
>> > good to display the fact that a process has terminated.
>> 
>> This side I understand, but what about the other: why should we not
>> check process status in the case where we are not redisplaying?

> Because Emacs generally looks at process output only when it's idle?

I don't follow: we're talking about when should
wait_reading_process_output check status_notify.

So to repeat/rephrase my question: why doesn't
wait_reading_process_output call status_notify when it is passed a zero
do_display?


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So to repeat/rephrase my question: why doesn't
> wait_reading_process_output call status_notify when it is passed a
> zero do_display?

I don't see any good reason, but the current behavior seems to work OK
for !noninteractive.

Re: bug#141: Process sentinel not called in batch mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  141@emacsbugs.donarmstrong.com,  cyd@stupidchicken.com,  eller.helmut@gmail.com,  emacs-devel@gnu.org,  bug-submit-list@donarmstrong.com,  bug-gnu-emacs@gnu.org
> Date: Fri, 16 May 2008 12:57:16 -0400
> 
> >> This side I understand, but what about the other: why should we not
> >> check process status in the case where we are not redisplaying?
> 
> > Because Emacs generally looks at process output only when it's idle?
> 
> I don't follow: we're talking about when should
> wait_reading_process_output check status_notify.
> 
> So to repeat/rephrase my question: why doesn't
> wait_reading_process_output call status_notify when it is passed a zero
> do_display?

Sorry, let me explain my line of thought in more detail: Emacs only
does a redisplay when it is idle.  Emacs also checks input from
subprocesses when it is idle.  If we are not in redisplay, it means
Emacs is not idle, and so it makes sense not to check for subprocess
output at that time.

Does this make any sense?

Re: bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

>> >> This side I understand, but what about the other: why should we not
>> >> check process status in the case where we are not redisplaying?
>> 
>> > Because Emacs generally looks at process output only when it's idle?
>> 
>> I don't follow: we're talking about when should
>> wait_reading_process_output check status_notify.
>> 
>> So to repeat/rephrase my question: why doesn't
>> wait_reading_process_output call status_notify when it is passed a zero
>> do_display?

> Sorry, let me explain my line of thought in more detail: Emacs only
> does a redisplay when it is idle.  Emacs also checks input from
> subprocesses when it is idle.  If we are not in redisplay, it means
> Emacs is not idle, and so it makes sense not to check for subprocess
> output at that time.

> Does this make any sense?

But if we're in wait_reading_process_output, that means that idle or
not, we're checking for process output, so why not check for process
status changes as well?


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  141@emacsbugs.donarmstrong.com,  cyd@stupidchicken.com,  eller.helmut@gmail.com,  emacs-devel@gnu.org,  bug-submit-list@donarmstrong.com,  bug-gnu-emacs@gnu.org
> Date: Fri, 16 May 2008 15:24:04 -0400
> 
> >> >> This side I understand, but what about the other: why should we not
> >> >> check process status in the case where we are not redisplaying?
> >> 
> >> > Because Emacs generally looks at process output only when it's idle?
> >> 
> >> I don't follow: we're talking about when should
> >> wait_reading_process_output check status_notify.
> >> 
> >> So to repeat/rephrase my question: why doesn't
> >> wait_reading_process_output call status_notify when it is passed a zero
> >> do_display?
> 
> > Sorry, let me explain my line of thought in more detail: Emacs only
> > does a redisplay when it is idle.  Emacs also checks input from
> > subprocesses when it is idle.  If we are not in redisplay, it means
> > Emacs is not idle, and so it makes sense not to check for subprocess
> > output at that time.
> 
> > Does this make any sense?
> 
> But if we're in wait_reading_process_output, that means that idle or
> not, we're checking for process output, so why not check for process
> status changes as well?

Because status_notify has a side effect of triggering redisplay.

Re: bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

>> >> >> This side I understand, but what about the other: why should we not
>> >> >> check process status in the case where we are not redisplaying?
>> >> 
>> >> > Because Emacs generally looks at process output only when it's idle?
>> >> 
>> >> I don't follow: we're talking about when should
>> >> wait_reading_process_output check status_notify.
>> >> 
>> >> So to repeat/rephrase my question: why doesn't
>> >> wait_reading_process_output call status_notify when it is passed a zero
>> >> do_display?
>> 
>> > Sorry, let me explain my line of thought in more detail: Emacs only
>> > does a redisplay when it is idle.  Emacs also checks input from
>> > subprocesses when it is idle.  If we are not in redisplay, it means
>> > Emacs is not idle, and so it makes sense not to check for subprocess
>> > output at that time.
>> 
>> > Does this make any sense?
>> 
>> But if we're in wait_reading_process_output, that means that idle or
>> not, we're checking for process output, so why not check for process
>> status changes as well?

> Because status_notify has a side effect of triggering redisplay.

Thanks.  Now it makes a lot more sense.  Please add a corresponding
comment on the do_display check.


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But if we're in wait_reading_process_output, that means that idle or
>>> not, we're checking for process output, so why not check for process
>>> status changes as well?
>
>> Because status_notify has a side effect of triggering redisplay.
>
> Thanks.  Now it makes a lot more sense.  Please add a corresponding
> comment on the do_display check.

What do you think should be the fix for the original problem?

Re: bug#141: Process sentinel not called in batch mode

[Stefan Monnier]

>>>> But if we're in wait_reading_process_output, that means that idle or
>>>> not, we're checking for process output, so why not check for process
>>>> status changes as well?
>> 
>>> Because status_notify has a side effect of triggering redisplay.
>> 
>> Thanks.  Now it makes a lot more sense.  Please add a corresponding
>> comment on the do_display check.

> What do you think should be the fix for the original problem?

The one you proposed seems right,


        Stefan

Re: bug#141: Process sentinel not called in batch mode

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> But if we're in wait_reading_process_output, that means that idle or
>>>>> not, we're checking for process output, so why not check for process
>>>>> status changes as well?
>>> 
>>>> Because status_notify has a side effect of triggering redisplay.
>>> 
>>> Thanks.  Now it makes a lot more sense.  Please add a corresponding
>>> comment on the do_display check.
>
>> What do you think should be the fix for the original problem?
>
> The one you proposed seems right,

OK.  I've checked it in.

Process sentinel not called in batch mode

[Helmut Eller]

process-sentinels aren't called in batch mode.  I'm not sure if this is
a bug or the expected behavior, but I find this quite frustrating.
To reproduce the problem do:

$shell> cat test-sentinel.el

(defvar sentinel-called nil)

(defun start-subprocess ()
  (let ((proc (start-process "test" nil "bash" "-c" "sleep 1 ; exit 20")))
    (set-process-sentinel proc (lambda (proc msg)
				 (message "sentinel: %S %s" proc msg)
				 (setq sentinel-called t)))
    proc))

(defun print-status (proc)
  (message "%s status: %s exit-status: %s sentinel-called: %s" 
	   proc (process-status proc) (process-exit-status proc) 
	   sentinel-called))

(defun main ()
  (let ((proc (start-subprocess)))
    (while (not sentinel-called)
      (print-status proc)
      (sit-for 1)
      (accept-process-output proc 1))
    (print-status proc)))

(main)

$shell> emacs -Q -batch -l test-sentinel.el
test status: run exit-status: 0 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil

[Exit 130 (SIGINT)]
$shell>

Emacs can obviously detect that the suprocess has terminated but the
sentinel is never called.  This used to work with Emacs 20.7 and for
certain variants of the 22.0.50 series.

Helmut.


In GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2008-03-14 on xaital
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-jpeg=no' '--with-gif=no' '--with-tiff=no' '--with-xft' '--without-dbus' '--without-sound''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: nil

Major mode: Emacs-Lisp

Minor modes in effect:
  outline-minor-mode: t
  display-time-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<up> <up> <up> <down> <down> <up> <up> <up> <up> <up> 
<up> <up> <down> <down> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <left> <left> <left> 
<left> <left> <left> C-d C-M-x C-x C-s <down> C-e <down> 
<down> <up> C-x C-e <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> C-x C-e C-x b * M e <tab> <return> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> C-x b 
<return> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> C-a C-d C-d 
C-d <up> <up> <up> <up> C-e <down> <down> C-e C-x C-s 
<down> <down> C-x C-s <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <up> <down> <down> <down> <down> 
<down> <down> <up> <up> C-x C-e <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> s e e <backspace> 
<backspace> l e e p 1 SPC ; SPC <left> <left> C-e C-x 
C-s <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
SPC C-x C-s <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <right> <right> b a C-x 
C-s M-x r e p SPC o <tab> SPC t SPC <backspace> r <tab> 
<return>

Recent messages:
test status: exit exit-status: 20 sentinel-called: t
"test status: exit exit-status: 20 sentinel-called: t"
Wrote /home/helmut/elisp/test-sentinel.el
(No changes need to be saved)
test status: run exit-status: 0 sentinel-called: t
"test status: run exit-status: 0 sentinel-called: t"
sentinel: #<process test> exited abnormally with code 20

Wrote /home/helmut/elisp/test-sentinel.el [3 times]
Making completion list... [3 times]

bug#141: marked as done (Process sentinel not called in batch mode)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]


Your message dated Mon, 19 May 2008 12:26:36 -0400
with message-id <873aoe5kg3.fsf@stupidchicken.com>
and subject line Re: bug#141: Process sentinel not called in batch mode
has caused the Emacs bug report #141,
regarding Process sentinel not called in batch mode
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
141: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=141
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 9668 bytes --]

From: Helmut Eller <eller.helmut@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: Process sentinel not called in batch mode
Date: Tue, 15 Apr 2008 16:48:00 +0200
Message-ID: <m2r6d7uqcf.fsf@gmail.com>


process-sentinels aren't called in batch mode.  I'm not sure if this is
a bug or the expected behavior, but I find this quite frustrating.
To reproduce the problem do:

$shell> cat test-sentinel.el

(defvar sentinel-called nil)

(defun start-subprocess ()
  (let ((proc (start-process "test" nil "bash" "-c" "sleep 1 ; exit 20")))
    (set-process-sentinel proc (lambda (proc msg)
				 (message "sentinel: %S %s" proc msg)
				 (setq sentinel-called t)))
    proc))

(defun print-status (proc)
  (message "%s status: %s exit-status: %s sentinel-called: %s" 
	   proc (process-status proc) (process-exit-status proc) 
	   sentinel-called))

(defun main ()
  (let ((proc (start-subprocess)))
    (while (not sentinel-called)
      (print-status proc)
      (sit-for 1)
      (accept-process-output proc 1))
    (print-status proc)))

(main)

$shell> emacs -Q -batch -l test-sentinel.el
test status: run exit-status: 0 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil
test status: exit exit-status: 20 sentinel-called: nil

[Exit 130 (SIGINT)]
$shell>

Emacs can obviously detect that the suprocess has terminated but the
sentinel is never called.  This used to work with Emacs 20.7 and for
certain variants of the 22.0.50 series.

Helmut.


In GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2008-03-14 on xaital
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-jpeg=no' '--with-gif=no' '--with-tiff=no' '--with-xft' '--without-dbus' '--without-sound''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: nil

Major mode: Emacs-Lisp

Minor modes in effect:
  outline-minor-mode: t
  display-time-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<up> <up> <up> <down> <down> <up> <up> <up> <up> <up> 
<up> <up> <down> <down> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <left> <left> <left> 
<left> <left> <left> C-d C-M-x C-x C-s <down> C-e <down> 
<down> <up> C-x C-e <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> C-x C-e C-x b * M e <tab> <return> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> C-x b 
<return> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> C-a C-d C-d 
C-d <up> <up> <up> <up> C-e <down> <down> C-e C-x C-s 
<down> <down> C-x C-s <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <up> <down> <down> <down> <down> 
<down> <down> <up> <up> C-x C-e <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> s e e <backspace> 
<backspace> l e e p 1 SPC ; SPC <left> <left> C-e C-x 
C-s <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
SPC C-x C-s <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <right> <right> b a C-x 
C-s M-x r e p SPC o <tab> SPC t SPC <backspace> r <tab> 
<return>

Recent messages:
test status: exit exit-status: 20 sentinel-called: t
"test status: exit exit-status: 20 sentinel-called: t"
Wrote /home/helmut/elisp/test-sentinel.el
(No changes need to be saved)
test status: run exit-status: 0 sentinel-called: t
"test status: run exit-status: 0 sentinel-called: t"
sentinel: #<process test> exited abnormally with code 20

Wrote /home/helmut/elisp/test-sentinel.el [3 times]
Making completion list... [3 times]





[-- Attachment #3: Type: message/rfc822, Size: 2298 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, 141-done@emacsbugs.donarmstrong.com, eller.helmut@gmail.com, emacs-devel@gnu.org
Subject: Re: bug#141: Process sentinel not called in batch mode
Date: Mon, 19 May 2008 12:26:36 -0400
Message-ID: <873aoe5kg3.fsf@stupidchicken.com>

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> But if we're in wait_reading_process_output, that means that idle or
>>>>> not, we're checking for process output, so why not check for process
>>>>> status changes as well?
>>> 
>>>> Because status_notify has a side effect of triggering redisplay.
>>> 
>>> Thanks.  Now it makes a lot more sense.  Please add a corresponding
>>> comment on the do_display check.
>
>> What do you think should be the fix for the original problem?
>
> The one you proposed seems right,

OK.  I've checked it in.

Re: bug#141: Process sentinel not called in batch mode

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But if we're in wait_reading_process_output, that means that idle or
> not, we're checking for process output, so why not check for process
> status changes as well?

Because we want to have all process output processed before registering
that the process has finished?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

bug#141: Process sentinel not called in batch mode

[Chong Yidong]

Helmut Eller <eller.helmut@gmail.com> wrote:

> process-sentinels aren't called in batch mode.  I'm not sure if this
> is a bug or the expected behavior, but I find this quite frustrating.
> To reproduce the problem do:
> $shell> cat test-sentinel.el

  (defvar sentinel-called nil)
  (defun main ()
    (let ((proc (start-process "test" nil "bash" "-c" "sleep 1 ; exit 20")))
      (set-process-sentinel proc (lambda (proc msg)
                                 (message "sentinel: %S %s" proc msg)
                                 (setq sentinel-called t)))
    (while (not sentinel-called)
      (message "status: %s exit-status: %s sentinel-called: %s" 
               (process-status proc) (process-exit-status proc) 
               sentinel-called)
      (sit-for 1)
      (accept-process-output proc 1))))
  (main)

> $shell> emacs -Q -batch -l test-sentinel.el

This problem occurs because wait_reading_process_output only calls
status_notify when given a nonzero DO_DISPLAY argument (process.c:4451).
Although wait_reading_process_output is called from many places in
Emacs, it is given a nonzero DO_DISPLAY argument only during
kbd_buffer_get_event.  But that function is never called in batch mode.

Maybe something like the attached patch should be applied.
Alternatively, we could change Faccept_process_output so that when Emacs
is in batch mode, it calls wait_reading_process_output with a nonzero
DO_DISPLAY argument.  Opinions?

*** trunk/src/process.c.~1.539.~	2008-04-09 13:46:04.000000000 -0400
--- trunk/src/process.c	2008-05-13 19:27:01.000000000 -0400
***************
*** 4414,4420 ****
  	 available, notify the user of the change right away.  After
  	 this explicit check, we'll let the SIGCHLD handler zap
  	 timeout to get our attention.  */
!       if (update_tick != process_tick && do_display)
  	{
  	  SELECT_TYPE Atemp;
  #ifdef NON_BLOCKING_CONNECT
--- 4414,4421 ----
  	 available, notify the user of the change right away.  After
  	 this explicit check, we'll let the SIGCHLD handler zap
  	 timeout to get our attention.  */
!       if (update_tick != process_tick
! 	  && (do_display || noninteractive))
  	{
  	  SELECT_TYPE Atemp;
  #ifdef NON_BLOCKING_CONNECT