Weird behavior of kill-emacs

Weird behavior of kill-emacs

[Philipp Stephani]

Hi,

kill-emacs contains the following code (
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n1899):

if (feof (stdin))
  arg = Qt;

According to git blame this was introduced in commit f927c5aed, the first
revision.
I suspect this code is responsible for the following somewhat surprising
behavior:

$ emacs -Q -batch -eval '(kill-emacs 37)' < /dev/null ; echo $?
37

$ emacs -Q -batch -eval '(progn (read) (kill-emacs 37))' < /dev/null ; echo
$?
Lisp expression: Error reading from stdin
0

So Emacs silently succeeds if it hit EOF of stdin, no matter what the exit
code passed to kill-emacs was!
This can be a problem for batch jobs that use kill-emacs, e.g.
ert-run-tests-batch-and-exit. Is this working as intended? If so, what's
the reason? Is there a way to work around this behavior?

Thanks,
Philipp

Re: Weird behavior of kill-emacs

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 18 Feb 2015 18:58:13 +0000
> 
> kill-emacs contains the following code (
> http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n1899):
> 
> if (feof (stdin))
>   arg = Qt;
> 
> According to git blame this was introduced in commit f927c5aed, the first
> revision.

Yes, so this code was there "forever".

> I suspect this code is responsible for the following somewhat surprising
> behavior:
> 
> $ emacs -Q -batch -eval '(kill-emacs 37)' < /dev/null ; echo $?
> 37
> 
> $ emacs -Q -batch -eval '(progn (read) (kill-emacs 37))' < /dev/null ; echo
> $?
> Lisp expression: Error reading from stdin
> 0
> 
> So Emacs silently succeeds if it hit EOF of stdin, no matter what the exit
> code passed to kill-emacs was!

I think in the second case kill-emacs isn't called at all, because
'read' signals an error.  Then Emacs exits because this is -batch
invocation.

> This can be a problem for batch jobs that use kill-emacs, e.g.
> ert-run-tests-batch-and-exit.

If you have a real-life use case where this produces problems, I
suggest to report it with report-emacs-bug.

> Is this working as intended?

I think so, yes.

> If so, what's the reason?

Reason for what? for that 'if' clause you mentioned?  It's to avoid
stuffing unread input when there's no one who will read it in the
first place.

> Is there a way to work around this behavior?

Why would you want to?

Re: Weird behavior of kill-emacs

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is there a way to work around this behavior?
>
> Why would you want to?

emacs < /dev/null -Q --batch --eval '(progn (ignore-errors (read)) (kill-emacs 42))'; echo $?

returns with exit code 0, i.e. the argument to kill-emacs is ignored.  I
guess the OP reads from stdin until EOF, which implies a fixed exit code
of 0.

-ap

Re: Weird behavior of kill-emacs

[Philipp Stephani]

Andreas Politz <politza@hochschule-trier.de> schrieb am Wed Feb 18 2015 at
9:07:44 PM:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Is there a way to work around this behavior?
> >
> > Why would you want to?
>
> emacs < /dev/null -Q --batch --eval '(progn (ignore-errors (read))
> (kill-emacs 42))'; echo $?
>
> returns with exit code 0, i.e. the argument to kill-emacs is ignored.  I
> guess the OP reads from stdin until EOF, which implies a fixed exit code
> of 0.
>

Exactly. In the case of the flycheck unit test suite the behavior is
triggered by some invocations of yes-or-no-p that try to read from stdin,
but it's closed, so this path is triggered and Emacs exits with a code of 0
even if the tests fail.

Re: Weird behavior of kill-emacs

[Philipp Stephani]

Eli Zaretskii <eliz@gnu.org> schrieb am Wed Feb 18 2015 at 8:35:25 PM:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 18 Feb 2015 18:58:13 +0000
> >
> > kill-emacs contains the following code (
> > http://git.savannah.gnu.org/cgit/emacs.git/tree/src/emacs.c#n1899):
> >
> > if (feof (stdin))
> >   arg = Qt;
> >
> > According to git blame this was introduced in commit f927c5aed, the first
> > revision.
>
> Yes, so this code was there "forever".
>
> > I suspect this code is responsible for the following somewhat surprising
> > behavior:
> >
> > $ emacs -Q -batch -eval '(kill-emacs 37)' < /dev/null ; echo $?
> > 37
> >
> > $ emacs -Q -batch -eval '(progn (read) (kill-emacs 37))' < /dev/null ;
> echo
> > $?
> > Lisp expression: Error reading from stdin
> > 0
> >
> > So Emacs silently succeeds if it hit EOF of stdin, no matter what the
> exit
> > code passed to kill-emacs was!
>
> I think in the second case kill-emacs isn't called at all, because
> 'read' signals an error.  Then Emacs exits because this is -batch
> invocation.
>

As Andreas' example shows, this behavior is observed even if no error is
signalled.
With an error signalled, I'd actually expect an exit code of 255, but I
guess the top-level catch handler calls kill-emacs as well, so the signal
exit code is eaten.


>
> > This can be a problem for batch jobs that use kill-emacs, e.g.
> > ert-run-tests-batch-and-exit.
>
> If you have a real-life use case where this produces problems, I
> suggest to report it with report-emacs-bug.
>

Will do. An example is flycheck: if you make the test/resources directory
read-only and then run the tests with closed stdin, the tests will fail,
but the exit code will be zero. This is a problem e.g. for continuous
integration systems that rely on a nonzero exit code for failing tests.


>
> > Is this working as intended?
>
> I think so, yes.
>
> > If so, what's the reason?
>
> Reason for what? for that 'if' clause you mentioned?  It's to avoid
> stuffing unread input when there's no one who will read it in the
> first place.
>

But the logic here is: if there is no unread input on stdin, exit with
status 0, no matter what happened before. I can't see how this behavior
could be useful.


>
> > Is there a way to work around this behavior?
>
> Why would you want to?
>
>
See above, this behavior means the exit code is not as expected. The
documentation for kill-emacs says:

"If ARG is an integer, return ARG as the exit program code."

But in fact that's not the case if EOF on stdin has been reached, then the
exit code is always 0.

Re: Weird behavior of kill-emacs

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philipp Stephani <p.stephani2@gmail.com>

>> According to git blame this was introduced in commit f927c5aed, the first
>> revision.
>
> Yes, so this code was there "forever".

According to bzr at least since 1991.

-ap

Re: Weird behavior of kill-emacs

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 18 Feb 2015 18:58:13 +0000
> 
> $ emacs -Q -batch -eval '(progn (read) (kill-emacs 37))' < /dev/null ; echo
> $?
> Lisp expression: Error reading from stdin
> 0
> 
> So Emacs silently succeeds if it hit EOF of stdin, no matter what the exit
> code passed to kill-emacs was!

I stand corrected: kill-emacs _is_ called.

Please report this as a bug.

Re: Weird behavior of kill-emacs

[Philipp Stephani]

Eli Zaretskii <eliz@gnu.org> schrieb am Wed Feb 18 2015 at 8:43:08 PM:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 18 Feb 2015 18:58:13 +0000
> >
> > $ emacs -Q -batch -eval '(progn (read) (kill-emacs 37))' < /dev/null ;
> echo
> > $?
> > Lisp expression: Error reading from stdin
> > 0
> >
> > So Emacs silently succeeds if it hit EOF of stdin, no matter what the
> exit
> > code passed to kill-emacs was!
>
> I stand corrected: kill-emacs _is_ called.
>
> Please report this as a bug.
>

Thanks, filed
http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-02/msg00623.html.

Re: Weird behavior of kill-emacs

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 18 Feb 2015 21:04:48 +0000
> 
> > Please report this as a bug.
> >
> 
> Thanks, filed
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-02/msg00623.html.

Thanks, fixed.