From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Using file descriptors in Emacs Date: Sun, 11 Sep 2016 12:00:21 -0400 Message-ID: <87d1ka1l62.fsf@earth.catern.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473609842 30604 195.159.176.226 (11 Sep 2016 16:04:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Sep 2016 16:04:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 11 18:03:59 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 1bj7EW-0006kh-2r for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 18:03:52 +0200 Original-Received: from localhost ([::1]:38222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7EU-0001SI-8d for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 12:03:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7BU-0007zr-Fn for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:00:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj7BR-0003dP-Cj for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:00:44 -0400 Original-Received: from [195.159.176.226] (port=55101 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7BR-0003ac-1o for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:00:41 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bj7BF-00010f-En for emacs-devel@gnu.org; Sun, 11 Sep 2016 18:00:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:v/zsslNUeuzomCnvTHYBEY99x/8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:207363 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 10 Sep 2016 10:28:44 -0400 >> Two features that I would like to add to eshell (or some shell in Emacs) >> that I believe will require the ability to directly manipulate file >> descriptors: >> >> - Piping data to and from processes without that data round-tripping through >> Emacs, which is necessary if I want to write a pipeline processing any >> significant amount of data (which I frequently do in even casual shell >> use) >> - Redirecting higher file descriptors than 0/1/2 (that is, when creating >> a process, before forking, use dup2 to rearrange what file descriptors are >> in what slots) > > It sounds like none of these two features need file descriptors to be > exposed to Lisp. Both of these sound like extensions of > start-process, and the descriptors could be dealt with entirely on the > C level, as applications shouldn't care about them. Am I missing > something? What kind of API based on extending start-process would allow these features to be used in full generality? 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. But to me that sounds somewhat unnatural for the process API. Are those the kind of extensions you were envisioning? Such extensions would work fine for my purposes.