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.