GNU bug report logs - #6963
Return an exit status to emacsclient

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6963 in the body.
You can then email your comments to 6963 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Arne Babenhauserheide <arne_bab <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; emacsclient -e "(remember-other-frame)" 
	doesn’t give an error-code on error.
Date: Wed, 1 Sep 2010 12:16:14 +0200

[Message part 1 (text/plain, inline)]

I wanted to use emacsclient with remember mode via 
   
    emacsclient -e "(remember-other-frame)" || emacsclient -ce "(remember-
other-frame)" 
   
to make sure that I get a remember field as fast as possible, whether I 
already have a frame or not. 
   
I get “*ERROR*: Unknown terminal type”, but the -ce command isn’t evoked. 
   
What I expected was to get an error code, so the second command gets called 
and gives me the remember frame. 
   
(which is darn useful, by the way!)

Best wishes and many thanks for working on emacs! It’s just great! 
Arne

--
Ich hab' nichts zu verbergen – hab ich gedacht: 

- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Schnerring <wosc <at> wosc.de>
To: 6963 <at> debbugs.gnu.org
Subject: More usecases, patch attached
Date: Wed, 29 Sep 2010 08:09:18 +0200

[Message part 1 (text/plain, inline)]

emacsclient is such a usefull tool. But that it does not signal error
situations via its exit status severely hinders its usage in shell
scripts or in integration with other programs.

For example, I was bit by this rather badly when I tried to use
emacsclient to start an ediff session, to use as a merge tool for the
Mercurial SCM.
I may have made a typo in configuring said ediff command or for
whatever other reason, Emacs returned an error. But Mercurial was
blissfully unaware of this, since emacsclient returns 0 no matter
what. End result: Mercurial committed a broken merge that I had to
spend at least two hours some days later to debug.

I've attached a patch that makes emacsclient exit with nonzero status
when it receives an error message from Emacs -- it already *prints*
"*ERROR*" in these cases, so I feel this makes a lot of sense.

Thanks,
Wolfgang

[emacsclient-exitstatus.patch (text/plain, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Wed, 29 Sep 2010 09:02:32 +0200

Wolfgang Schnerring <wosc <at> wosc.de> writes:

> emacsclient is such a usefull tool. But that it does not signal error
> situations via its exit status severely hinders its usage in shell
> scripts or in integration with other programs.
>
> For example, I was bit by this rather badly when I tried to use
> emacsclient to start an ediff session, to use as a merge tool for the
> Mercurial SCM.
> I may have made a typo in configuring said ediff command or for
> whatever other reason, Emacs returned an error. But Mercurial was
> blissfully unaware of this, since emacsclient returns 0 no matter
> what. End result: Mercurial committed a broken merge that I had to
> spend at least two hours some days later to debug.
>
> I've attached a patch that makes emacsclient exit with nonzero status
> when it receives an error message from Emacs -- it already *prints*
> "*ERROR*" in these cases, so I feel this makes a lot of sense.
>
> Thanks,
> Wolfgang
>

Did you use your own script or the mercurial script to use
emacsclient/ediff?

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #14 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Wolfgang Schnerring <wosc <at> wosc.de>
Cc: 6963 <at> debbugs.gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Wed, 29 Sep 2010 16:42:41 +0200

On Wed, Sep 29, 2010 at 08:09, Wolfgang Schnerring <wosc <at> wosc.de> wrote:

> But that it does not signal error
> situations via its exit status

It does in most cases.

> since emacsclient returns 0 no matter what.

That's not accurate. When emacsclient detects a problem with itself
(missing server file, error opening socket, etc.) it returns
EXIT_FAILURE (1). What it currently does not do, however, is returning
EXIT_FAILURE for errors passed back from Emacs.

> I've attached a patch that makes emacsclient exit with nonzero status
> when it receives an error message from Emacs -- it already *prints*
> "*ERROR*" in these cases, so I feel this makes a lot of sense.

Yes, it makes sense, because after -error the client's process is
deleted, so emacsclient exits immediately.

So, two questions remain:

- should this be considered a bug, and installed on emacs-23, or a new
feature, for the trunk?
- should emacsclient return 1 for these new errors, or a new error
code (2) to allow distinguishing them?

    Juanma

Message #17 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Schnerring <wosc <at> wosc.de>
To: 6963 <at> debbugs.gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Wed, 29 Sep 2010 17:08:05 +0200

* Juanma Barranquero <lekktu <at> gmail.com> [2010-09-29 16:42]:
> On Wed, Sep 29, 2010 at 08:09, Wolfgang Schnerring <wosc <at> wosc.de> wrote:
> > since emacsclient returns 0 no matter what.
> That's not accurate. When emacsclient detects a problem with itself
> (missing server file, error opening socket, etc.) it returns
> EXIT_FAILURE (1). What it currently does not do, however, is returning
> EXIT_FAILURE for errors passed back from Emacs.

Right. Your description is accurate, I was glossing over a bit too
much, sorry.
 
> - should this be considered a bug, and installed on emacs-23, or a new
> feature, for the trunk?

I personally consider it a bug, since everything else about "errors
from Emacs" is already there, only the exit status is missing. And
that really does not play nice with others.
(That said, this is a gray area, and one could probably also just as
well argue the opposite.)

> - should emacsclient return 1 for these new errors, or a new error
> code (2) to allow distinguishing them?

It probably makes sense to distinguish these, since they are different
types of errors, technical ("communication with Emacs failed") vs.
semantic ("Emacs said boo!").
One might want to invoke something that has known error cases, which
would benefit from being treated differently than a socket error or
somesuch.

Wolfgang

Message #20 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Wolfgang Schnerring <wosc <at> wosc.de>
Cc: 6963 <at> debbugs.gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Wed, 29 Sep 2010 17:43:16 +0200

On Wed, Sep 29, 2010 at 17:08, Wolfgang Schnerring <wosc <at> wosc.de> wrote:

> I personally consider it a bug, since everything else about "errors
> from Emacs" is already there, only the exit status is missing. And
> that really does not play nice with others.
> (That said, this is a gray area, and one could probably also just as
> well argue the opposite.)

I tend to agree with you about it being a bug, but OTOH I try to be
extremely conservative about committing changes into the release
branch, other than typos, docfixes, regression fixes and
very-obviously-correct bugfixes. That's the stated (though not always
followed) policy, and I think it's a very good one.

In this case, the patch changes the behavior of emacsclient, so even
if it fixes a bug, it could still affect users of emacsclient in
non-obvious ways (because, as you do, they could be using emacsclient
from scripts, tools, etc.). So I'd say it's best to keep this for the
trunk.

> It probably makes sense to distinguish these, since they are different
> types of errors, technical ("communication with Emacs failed") vs.
> semantic ("Emacs said boo!").
> One might want to invoke something that has known error cases, which
> would benefit from being treated differently than a socket error or
> somesuch.

I agree, and it doesn't make the patch more complicate (just one more line).

    Juanma

Message #23 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Schnerring <wosc <at> wosc.de>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 6963 <at> debbugs.gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Wed, 29 Sep 2010 20:01:29 +0200

* Juanma Barranquero <lekktu <at> gmail.com> [2010-09-29 17:43]:
> In this case, the patch changes the behavior of emacsclient, so even
> if it fixes a bug, it could still affect users of emacsclient in
> non-obvious ways (because, as you do, they could be using emacsclient
> from scripts, tools, etc.). So I'd say it's best to keep this for the
> trunk.

Yes, this change is "backwards incompatible", since, well, Emacs
errors will then return nonzero, duh ;-), and that might not match
current expectations. Anyway, it's your call, not mine.

Wolfgang

Message #26 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Wolfgang Schnerring <wosc <at> wosc.de>
Cc: 6963 <at> debbugs.gnu.org
Subject: Re: bug#6963: More usecases, patch attached
Date: Thu, 30 Sep 2010 03:52:22 +0200

On Wed, Sep 29, 2010 at 16:42, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> Yes, it makes sense, because after -error the client's process is
> deleted, so emacsclient exits immediately.

Hmm.

There are two cases:

1) The emacs server sends -error XXX, and closes the connection.
emacsclient prints the error and exits.
2) The emacs server sends an unknown command; emacsclient prints an
error and continues.

With your patch, the case 2) would return EXIT_FAILURE (or the new
exit code we discussed) even if subsequent commands are dealt with
correctly.

IIRC, receiving an unknown command from Emacs shouldn't be a fatal
error; it can happen if you use an older emacsclient to connect to a
more recent server.el with new functionality. Or should it?

Comments anyone?

    Juanma

Message #29 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 6963 <at> debbugs.gnu.org, Wolfgang Schnerring <wosc <at> wosc.de>
Subject: Re: bug#6963: More usecases, patch attached
Date: Sat, 02 Oct 2010 20:00:52 -0400

Juanma Barranquero <lekktu <at> gmail.com> writes:

> 1) The emacs server sends -error XXX, and closes the connection.
> emacsclient prints the error and exits.
> 2) The emacs server sends an unknown command; emacsclient prints an
> error and continues.
>
> With your patch, the case 2) would return EXIT_FAILURE (or the new
> exit code we discussed) even if subsequent commands are dealt with
> correctly.
>
> IIRC, receiving an unknown command from Emacs shouldn't be a fatal
> error; it can happen if you use an older emacsclient to connect to a
> more recent server.el with new functionality. Or should it?

I agree, the second case should not lead to EXIT_FAILURE.  I've checked
the patch, with this and a couple of other corrections, into the trunk.

Message #34 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 6963 <at> debbugs.gnu.org, Wolfgang Schnerring <wosc <at> wosc.de>
Subject: Re: bug#6963: More usecases, patch attached
Date: Sun, 3 Oct 2010 02:38:29 +0200

On Sun, Oct 3, 2010 at 02:00, Chong Yidong <cyd <at> stupidchicken.com> wrote:

> I agree, the second case should not lead to EXIT_FAILURE.  I've checked
> the patch, with this and a couple of other corrections, into the trunk.

OK, though I agree with Wolfgang that the first case would be more
useful returning a new EXIT_EMACSERROR (2) instead of EXIT_FAILURE
(1).

    Juanma

Message #37 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 6963 <at> debbugs.gnu.org, Wolfgang Schnerring <wosc <at> wosc.de>
Subject: Re: bug#6963: More usecases, patch attached
Date: Sun, 03 Oct 2010 00:55:40 -0400

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sun, Oct 3, 2010 at 02:00, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>
>> I agree, the second case should not lead to EXIT_FAILURE.  I've checked
>> the patch, with this and a couple of other corrections, into the trunk.
>
> OK, though I agree with Wolfgang that the first case would be more
> useful returning a new EXIT_EMACSERROR (2) instead of EXIT_FAILURE
> (1).

I'm ambivalent.  This argument implies that we should give different
exit code for everything that could lead to failure in emacsclient, and
there are 18 separate cases in emacsclient.c.  It seems to me that, in
practice, people don't bother looking up the exit code, since there's no
established convention (other than 0 for success and 1 for failure);
they just look at the error message.

Message #40 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 6963 <at> debbugs.gnu.org, Wolfgang Schnerring <wosc <at> wosc.de>
Subject: Re: bug#6963: More usecases, patch attached
Date: Sun, 3 Oct 2010 12:44:44 +0200

On Sun, Oct 3, 2010 at 06:55, Chong Yidong <cyd <at> stupidchicken.com> wrote:

> I'm ambivalent.  This argument implies that we should give different
> exit code for everything that could lead to failure in emacsclient, and
> there are 18 separate cases in emacsclient.c.

Well, I don't think so. All 18 cases are clearly separated into:

 - emacsclient had a problem (unable to create socket, bad
authorization file, etc.)
 - emacsclient worked fine, but Emacs had a problem.

but I suppose there's no harm in waiting for some use case before
going that route.

    Juanma

Message #43 received at 6963 <at> debbugs.gnu.org (full text, mbox):

From: Arne Babenhauserheide <arne_bab <at> yahoo.de>
To: 6963 <at> debbugs.gnu.org
Subject: Thank you!
Date: Fri, 22 Oct 2010 23:23:35 +0200

Many thanks for including the patch (and for writing it)!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.