From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Using file descriptors in Emacs Date: Sun, 11 Sep 2016 19:39:06 +0300 Message-ID: <8337l6bdcl.fsf@gnu.org> References: <1465262706-5229-1-git-send-email-sbaugh@catern.com> <87twfevqu7.fsf@earth.catern.com> <87pood5fee.fsf@earth.catern.com> <834m5p83yy.fsf@gnu.org> <877fal56zh.fsf@earth.catern.com> <83d1kcaowk.fsf@gnu.org> <8737l86glg.fsf@earth.catern.com> <837fakan8b.fsf@gnu.org> <87r38s4xmv.fsf@earth.catern.com> <83oa3w8byt.fsf@gnu.org> <87twdn25ib.fsf@earth.catern.com> <83d1kabgms.fsf@gnu.org> <87d1ka1l62.fsf@earth.catern.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473611990 29697 195.159.176.226 (11 Sep 2016 16:39:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Sep 2016 16:39:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 11 18:39:46 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj7nG-0007Ae-GR for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 18:39:46 +0200 Original-Received: from localhost ([::1]:38360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7nB-0007V1-Vq for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 12:39:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7mg-0007Uv-Ug for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:39:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj7md-0005q2-PP for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:39:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7md-0005pl-M5; Sun, 11 Sep 2016 12:39:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bj7mb-0007is-PU; Sun, 11 Sep 2016 12:39:06 -0400 In-reply-to: <87d1ka1l62.fsf@earth.catern.com> (sbaugh@catern.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207365 Archived-At: > From: sbaugh@catern.com > Date: Sun, 11 Sep 2016 12:00:21 -0400 > > I suppose one could add the capability to pass in a process object as > the source of input for a new process object. This could be implemented > by forcing the passed-in process object to a state where it does not > have (and cannot have) a process-filter function. Then the file > descriptor used for input to the passed-in process object could be > manipulated appropriately to make it the stdin of the new process > object. The new process object in turn will be in a special state where > it cannot accept input from Emacs. > > Likewise for the capability to pass in a process object as the > destination for a program's output, instead of a process-filter, and the > capability to redirect arbitrary file descriptor numbers to point at > process objects (or other file descriptors). > > Then also it is necessary to handle redirecting to and from files > without going through Emacs. That could be done by creating a new kind > of process object which is created by opening a file, and then that can > be passed in in the way I describe above. Yes, something like that. > But to me that sounds somewhat unnatural for the process API. To me it sounds most natural. All of our APIs in this area are like that. > Are those the kind of extensions you were envisioning? Yes. Btw, running a pipe of processes raises another issue, unrelated to file descriptors: we would need a way to make sure the processes do not start running until all the redirections are set up, otherwise some of them will die with SIGPIPE or somesuch.