Re: pipe

[Eli Zaretskii <eliz@gnu.org>]

> From: Daiki Ueno <ueno@gnu.org>
> Cc: Werner Koch <wk@gnupg.org>,  emacs-devel@gnu.org
> Date: Tue, 17 Mar 2015 16:22:07 +0900
> 
> Eli Zaretskii <eliz@gnu.org> 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.