GNU bug report logs - #60592
30.0.50; emacsclient: exit with a different code when the request times out

Previous Next

Package: emacs;

Reported by: Sean Whitton <spwhitton <at> spwhitton.name>

Date: Fri, 6 Jan 2023 05:48:02 UTC

Severity: normal

Found in version 30.0.50

To reply to this bug, email your comments to 60592 AT debbugs.gnu.org.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#60592; Package emacs. (Fri, 06 Jan 2023 05:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sean Whitton <spwhitton <at> spwhitton.name>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 06 Jan 2023 05:48:02 GMT) Full text and rfc822 format available.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; emacsclient: exit with a different code when the request
 times out
Date: Thu, 05 Jan 2023 22:47:49 -0700
Hello,

When calling 'emacsclient --timeout N --eval' from scripts, it would be
nice if you could determine for sure when a failure was just due to a
timeout, rather than, say, a Lisp exception.

inotifywait(1) exits with code 2 to indicate a timeout.
emacsclient could do the same.

We might then consider adding a separate exit code for a Lisp error.
Then a failure of emacsclient to connect, a request that timed out, and
an error from Lisp would be readily distinguishable.

At present the best one could do is parse emacsclient's output, but
that doesn't seem robust.

-- 
Sean Whitton




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60592; Package emacs. (Fri, 06 Jan 2023 07:38:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50;
 emacsclient: exit with a different code when the request times out
Date: Fri, 06 Jan 2023 09:37:11 +0200
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Thu, 05 Jan 2023 22:47:49 -0700
> 
> When calling 'emacsclient --timeout N --eval' from scripts, it would be
> nice if you could determine for sure when a failure was just due to a
> timeout, rather than, say, a Lisp exception.
> 
> inotifywait(1) exits with code 2 to indicate a timeout.
> emacsclient could do the same.

It would be more portable to have the exception handler send a special
message to emacsclient, so that it would know the reason without
guessing.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60592; Package emacs. (Fri, 06 Jan 2023 17:58:02 GMT) Full text and rfc822 format available.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 10:57:18 -0700
Hello,

On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Thu, 05 Jan 2023 22:47:49 -0700
>>
>> When calling 'emacsclient --timeout N --eval' from scripts, it would be
>> nice if you could determine for sure when a failure was just due to a
>> timeout, rather than, say, a Lisp exception.
>>
>> inotifywait(1) exits with code 2 to indicate a timeout.
>> emacsclient could do the same.
>
> It would be more portable to have the exception handler send a special
> message to emacsclient, so that it would know the reason without
> guessing.

I think this is wholly complimentary to what I'm suggesting, right?

-- 
Sean Whitton




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60592; Package emacs. (Fri, 06 Jan 2023 18:13:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 20:12:45 +0200
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 60592 <at> debbugs.gnu.org
> Date: Fri, 06 Jan 2023 10:57:18 -0700
> 
> Hello,
> 
> On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:
> 
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Date: Thu, 05 Jan 2023 22:47:49 -0700
> >>
> >> When calling 'emacsclient --timeout N --eval' from scripts, it would be
> >> nice if you could determine for sure when a failure was just due to a
> >> timeout, rather than, say, a Lisp exception.
> >>
> >> inotifywait(1) exits with code 2 to indicate a timeout.
> >> emacsclient could do the same.
> >
> > It would be more portable to have the exception handler send a special
> > message to emacsclient, so that it would know the reason without
> > guessing.
> 
> I think this is wholly complimentary to what I'm suggesting, right?

I didn't think so, but maybe I was missing something.

My point is that if we make the exception known to emacsclient, then
when the timeout ends without exceptions, it should be clear it was a
real timeout.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60592; Package emacs. (Fri, 06 Jan 2023 19:04:02 GMT) Full text and rfc822 format available.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 12:03:17 -0700
Hello,

On Fri 06 Jan 2023 at 08:12PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: 60592 <at> debbugs.gnu.org
>> Date: Fri, 06 Jan 2023 10:57:18 -0700
>>
>> Hello,
>>
>> On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:
>>
>> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> >> Date: Thu, 05 Jan 2023 22:47:49 -0700
>> >>
>> >> When calling 'emacsclient --timeout N --eval' from scripts, it would be
>> >> nice if you could determine for sure when a failure was just due to a
>> >> timeout, rather than, say, a Lisp exception.
>> >>
>> >> inotifywait(1) exits with code 2 to indicate a timeout.
>> >> emacsclient could do the same.
>> >
>> > It would be more portable to have the exception handler send a special
>> > message to emacsclient, so that it would know the reason without
>> > guessing.
>>
>> I think this is wholly complimentary to what I'm suggesting, right?
>
> I didn't think so, but maybe I was missing something.
>
> My point is that if we make the exception known to emacsclient, then
> when the timeout ends without exceptions, it should be clear it was a
> real timeout.

Right.  This is a good addition to my proposal -- no conflicts.

-- 
Sean Whitton




This bug report was last modified 1 year and 82 days ago.

Previous Next


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