From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: pipe Date: Tue, 17 Mar 2015 10:47:20 +0200 Message-ID: <8361a0yprb.fsf@gnu.org> References: <83twxp2mew.fsf@gnu.org> <87h9tp3wsp.fsf-ueno@gnu.org> <87wq2kd5je.fsf@vigenere.g10code.de> <83d24c2c2p.fsf@gnu.org> <87d24bdcgr.fsf@vigenere.g10code.de> <838uez3dcj.fsf@gnu.org> <87y4mzbcqm.fsf@vigenere.g10code.de> <83pp8b1foi.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1426582072 2545 80.91.229.3 (17 Mar 2015 08:47:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Mar 2015 08:47:52 +0000 (UTC) Cc: wk@gnupg.org, emacs-devel@gnu.org To: Daiki Ueno Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 17 09:47:44 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YXnA7-0006eV-ET for ged-emacs-devel@m.gmane.org; Tue, 17 Mar 2015 09:47:43 +0100 Original-Received: from localhost ([::1]:53382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXnA6-0007mT-DI for ged-emacs-devel@m.gmane.org; Tue, 17 Mar 2015 04:47:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:61000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXnA2-0007mC-6S for emacs-devel@gnu.org; Tue, 17 Mar 2015 04:47:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXn9y-00087j-3n for emacs-devel@gnu.org; Tue, 17 Mar 2015 04:47:38 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXn9x-00087Y-Ro; Tue, 17 Mar 2015 04:47:34 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NLC00H00LPX5700@a-mtaout23.012.net.il>; Tue, 17 Mar 2015 10:47:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLC00HTQLR73R20@a-mtaout23.012.net.il>; Tue, 17 Mar 2015 10:47:31 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183945 Archived-At: > From: Daiki Ueno > Cc: Werner Koch , emacs-devel@gnu.org > Date: Tue, 17 Mar 2015 16:22:07 +0900 > > Eli Zaretskii writes: > > >> > But that means it would be impossible to invoke gpg from a shell that > >> > can redirect handles beyond the first 3, like some decent port of > >> > Bash, is that correct? Or is that where the wrapper comes into play, > >> > >> I don't know about a native Bash port to Windows. Using Cygwin with > >> native Windows programs is problematic has you probably know. > > > > I was thinking about MSYS Bash. But any port of Bash should do, as > > redirecting file handles for a sub-process is trivial. > > Thanks for all the information. I'm almost lost :-) Welcome to the club ;-) > Are the following assumptions correct? > > - A subprocess on Windows is able to access a handle passed as an > external representation from the parent, as described in the first > example of: > https://msdn.microsoft.com/en-us/library/aa298531%28v=vs.60%29.aspx Yes. (But what is passed on the command line is not the HANDLE, it's the file descriptor; the corresponding HANDLE is passed behind the scenes, AFAIK, using the undocumented fields of the STARTUPINFO structure.) Please note that the magic that passes the inherited HANDLEs to the child process is in the Windows C runtime, as part of the implementation of the "spawn*" family of functions. Emacs bypasses "spawn*" and has its own implementation of 'spawnve', which doesn't include the equivalent code. So if we want Emacs to be able to use pipes that use file descriptors beyond the 3 standard ones, we will have to add the code which passes the corresponding HANDLEs. > - Some shells maintain the mappings between file descriptors and > handles, and if Emacs runs a shell program with a redirection to > non-standard file descriptors, it might not work as expected I don't understand what you are saying here. Please elaborate, or give an example. What I meant is this: . Werner says that the --status-fd etc. options need to have HANDLEs as arguments on Windows, not file descriptors. . Invoking gpg from Bash with the likes of ">&5" doesn't provide a way of finding out the HANDLE that corresponds to the file descriptor 5, and so I'm unsure how can the gpg command line be constructed using HANDLE values instead of descriptors. The mapping between file descriptors and the corresponding HANDLEs is maintained by the C runtime for each process, and there are 2 library functions to get the HANDLE given a descriptor, and a descriptor for a handle. But I'm not aware of a way of getting these mappings from the shell's prompt. > - Emacs uses Gnulib's pipe2 implementation around _pipe on native > Windows and the returned file descriptors are actually a handle No, Emacs uses its own implementation of pipe2 (see w32.c), which returns file descriptors. (And I think you are mistaken about the Gnulib implementation: it also returns file descriptors, not HANDLEs, because the '_pipe' call returns descriptors.) > If all of those are correct, perhaps we could just mention the fact that > the child ends of a pipe process is a handle on Windows? Not all of those are correct, but I'm unsure what the implications are, see above. > In any case, supporting stderr could be a starting point, as it seems to > be a long-standing request: > https://lists.gnu.org/archive/html/emacs-devel/2004-04/msg01051.html > and it wouldn't involve a portability issue. Redirecting the child's stderr is already supported on Windows, so this is only a matter of having the higher layers DTRT.