From: andrewi AT harlequin DOT co DOT uk (Andrew Innes)
Subject: Re: Problems with call-process-region under Cygwin b19
7 Mar 1998 11:03:46 -0800
Message-ID: <199803051409.OAA19800.cygnus.gnu-win32@shirow.long.harlequin.co.uk>
References: <9803051335 DOT AA13992 AT rodin DOT wustl DOT edu>
To: kevin AT rodin DOT wustl DOT edu
Cc: ntemacs-users AT cs DOT washington DOT edu, gnu-win32 AT cygnus DOT com

On Thu, 5 Mar 1998 07:35:46 -0600 (CST), kevin AT rodin DOT wustl DOT edu (Kevin Ruland) said:
>
>Andrew,
>
>I didn't realize I hadn't been bouncing this past the list too.

You hadn't - I copied my last message to the list, since we seem to have
uncovered the real problem.

>>I presume this used the Cygnus port of od - so it might be that b19
>>programs do not pass on stdin correctly to subprocesses that aren't
>>themselves compiled with cygwin32.
>
>I started a standard bash shell and executed:
>
>hexl -hex < hexl.exe
>
>and all seemed okay.  Does emacs do something differently?

Emacs sets up stdin/stdout/stderr as required when starting a subprocess
(so stdin will be a handle to a temp file containing the data from the
region, in the case of call-process-region).  This all works fine.

>>If you change shell temporarily back to cmdproxy, does hexlify-buffer
>>work then?  If so, then this must be a bug in cygwin32 b19.
>
>I tried switching to b18 bash and hexlify-buffer works fine. So does
>hexl-find-file, and call-process-region.
>
>Seems I'm barkin' up the wrong tree.  I'll continue to pursue this with the
>cygnus folks.  Perhaps they should have been included in the first place.
>
>I did find this blurb in the b19 release notes which might be a hint:
>
>Note that a B19-compiled application exec()ing a B18-compiled
>application will treat the B18-compiled executable as an ordinary Win32
>executable. This means that open file descriptors and some other
>internals will not be inheritted on exec() calls.  The reason for this
>is that different shared memory areas are used by the different
>versions of the cygwin library. This may or may not be of importance to
>you depending on what you're doing.

I'd read this before, but assumed it meant that open file descriptors
_other than the standard three_ would not be inherited (which is fair
enough).  It looks like in fact at least some of the standard handles
aren't being inherited by normal Win32 applications.

That is, bash definitely inherits the correct handles from Emacs, but is
not passing them (all) on to hexl.exe, apparently because hexl.exe is
not a b19-compiled app.

I've copied this to the gnu-win32 list, just in case this hasn't been
reported already (I couldn't see it in the mailing list archive).

AndrewI

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".