[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe i
From: |
Eli Zaretskii |
Subject: |
bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken |
Date: |
Sat, 19 Feb 2022 22:19:26 +0200 |
> Cc: 54062@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sat, 19 Feb 2022 12:02:45 -0800
>
> > SIGPIPE isn't supported on MS-Windows, so I think we should have a
> > fallback there for platforms that don't support SIGPIPE.
>
> Hmm, good point. Thinking about this some more, this also won't work for
> Tramp (which only supports `interrupt-process' as far as I can tell). I
> can think of a couple possible solutions.
>
> One option would be to call `interrupt-process' instead, since that
> works in all cases I'm aware of. This isn't quite as nice as sending
> SIGPIPE (or equivalent) to let the process handle it how it wants, but
> at least `interrupt-process' has the same default behavior as SIGPIPE
> (i.e. terminate the process).
Many console programs catch SIGINT, though.
Can't we terminate ("kill") the process instead? Or maybe deleting
the process object is enough?
> Another way would be to add a function like `process-break-pipe' (it
> could probably use a better name) that would close the read end of the
> process's output pipe, which - if I understand the Win32 API here -
> should trigger the right behavior on MS Windows too.
You mean, delete the process object? That's how we close our end of
the pipe, no?
> One caveat is that the head process (`yes' in the example), would only
> see the "broken pipe" error on the *next* write after the one where
> Eshell detected the broken pipe. That's easy enough to fix for cases
> where we can signal SIGPIPE directly, but it's probably ok in general
> too: after all, processes don't generally know exactly when a SIGPIPE
> might occur, so it occurring slightly later shouldn't cause problems.
I don't see a problem here. AFAIU, closing a pipe doesn't always
deliver SIGPIPE, it can instead fail the write with EPIPE. So SIGPIPE
is not guaranteed anyway.
> (In theory, the tail process should call `process-break-pipe' as soon as
> it closes, but in Eshell, the tail process doesn't know what's feeding
> it input, so it can't easily do this.)
Not sure I understand: an Emacs process object always knows what's
feeding it.
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/18
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Eli Zaretskii, 2022/02/19
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/19
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken,
Eli Zaretskii <=
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/19
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Eli Zaretskii, 2022/02/20
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/20
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Eli Zaretskii, 2022/02/21
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Lars Ingebrigtsen, 2022/02/21
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Eli Zaretskii, 2022/02/21
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/21
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Eli Zaretskii, 2022/02/22
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Jim Porter, 2022/02/22
- bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken, Lars Ingebrigtsen, 2022/02/23