GNU bug report logs - #79079
31.0.50; Piped command output is sometimes lost in Eshell

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, 79079 <at> debbugs.gnu.org
Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell
Date: Thu, 24 Jul 2025 12:06:16 -0700

On 7/24/2025 11:50 AM, Paul Eggert wrote:
> On 2025-07-24 10:05, Jim Porter wrote:
>> Could there be a time when we get an error from 'process-send-string', 
>> but we can try calling it again later?
> 
> Not if it's an EPIPE failure. EPIPE means the connection is permanently 
> down.

Right. I was just wondering if there might be some use in signaling 
different types of errors in send_process; one for transient errors (if 
there are any we care about), and one for permanent errors (which look 
to be most/all of them).

> I don't offhand know of any failure for writing to a pipe where retrying 
> would make sense, other than EAGAIN and EWOULDBLOCK which the code is 
> already dealing with.
> 
> Can process-send-string write to other file types? If so, there are 
> other possibilities where retrying might work, e.g., ENOSPC for write to 
> a regular file, ENETDOWN for sendto to a network socket.

For Eshell, we only support writing to regular processes, though I 
suppose with enough effort you could probably construct an Eshell 
command that writes to a socket. Of course, for something like ENETDOWN, 
Eshell would probably need some special handling to retry sending the 
same data again, instead of just skipping over it.

Previous Next

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