From: Eli Zaretskii <eliz@gnu.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: 54062@debbugs.gnu.org
Subject: bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken
Date: Sun, 20 Feb 2022 09:27:08 +0200 [thread overview]
Message-ID: <83a6emxak3.fsf@gnu.org> (raw)
In-Reply-To: <b84804be-3a11-3c68-65a3-3ca534ca2e35@gmail.com> (message from Jim Porter on Sat, 19 Feb 2022 13:18:16 -0800)
> Cc: 54062@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sat, 19 Feb 2022 13:18:16 -0800
>
> > Many console programs catch SIGINT, though.
> >
> > Can't we terminate ("kill") the process instead? Or maybe deleting
> > the process object is enough?
>
> That might work; it would definitely be better than `interrupt-process'.
> On the other hand, I think it would be nice to handle this case by
> breaking the pipe if possible, since that would be closer to how it
> works in regular shells, as I understand it.
I meant killing the process as fallback for when SIGPIPE is not
supported.
> >> 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?
>
> Do you mean using `delete-process'? That works differently from how I'm
> imagining things. From reading the code, `delete-process' sends SIGKILL
> to the process group, but that means that a process that wants to do
> something special in response to SIGPIPE (or EPIPE, or ERROR_BROKEN_PIPE
> on Win32) wouldn't be able to, since that's not the signal/error it
> receives.
How else can you close the pipe without deleting the process? How can
Emacs have a process whose I/O channels aren't ready to be used?
I thought you were talking about a pipe process (make-pipe-process),
in which case deleting it closes the pipe. But you seem to mean
something else, so now I'm not sure I understand.
> In my patch, `process-break-pipe' just closes the file descriptor for
> the read end of the process's stdout pipe, but otherwise doesn't do
> anything to the process.
I don't think this is a good idea. A process isn't supposed to be in
this state.
> Then, when the process tries to write to stdout
> again, the OS will report (via a signal and/or an error code) that the
> pipe is broken. Since Win32's WriteFile[1] API returns ERROR_BROKEN_PIPE
> in this case, that would let MS Windows programs detect and respond to
> broken pipes in the usual way for that platform.
We don't use WriteFile directly, and I wouldn't rely on EPIPE being in
errno in this case without extensive testing.
Anyway, the proposal to close the pipe of a live process object is
problematic, see above. I hope we can come up with something
simpler. We are talking about a niche feature here, so it is IMO
better to find a simple solution for that.
next prev parent reply other threads:[~2022-02-20 7:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-19 4:20 bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken Jim Porter
2022-02-19 8:35 ` Eli Zaretskii
2022-02-19 20:02 ` Jim Porter
2022-02-19 20:19 ` Eli Zaretskii
2022-02-19 21:18 ` Jim Porter
2022-02-20 7:27 ` Eli Zaretskii [this message]
2022-02-20 20:17 ` Jim Porter
2022-02-21 17:15 ` Eli Zaretskii
2022-02-21 17:39 ` Lars Ingebrigtsen
2022-02-21 18:31 ` Eli Zaretskii
2022-02-21 20:37 ` Jim Porter
2022-02-22 13:09 ` Eli Zaretskii
2022-02-22 16:49 ` Jim Porter
2022-02-23 12:14 ` Lars Ingebrigtsen
2022-02-24 5:20 ` Jim Porter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83a6emxak3.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=54062@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).