X-Spam-Check-By:	sourceware.org
Message-ID:	<44543FE2.5070208@arkasoft.com>
Date:	Sun, 30 Apr 2006 05:41:06 +0100
From:	Kaveh Goudarzi <kaveh AT arkasoft DOT com>
User-Agent:	Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
References:	<44542B34 DOT 9000907 AT arkasoft DOT com>
In-Reply-To:	<44542B34.9000907@arkasoft.com>
X-DSPAM-Result:	Innocent
X-DSPAM-Processed:	Sun Apr 30 05:41:19 2006
X-DSPAM-Confidence:	0.5820
X-DSPAM-Probability:	0.0000
X-DSPAM-Signature:	44543fef237328539715904
X-DSPAM-Factors:	27,
X-Spam-Score:	1.415
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Hi Eric/Brian,
	
	Thanks for your responses.  I hope you don't mind
answering a few more questions :-)

1. is it possible to somehow force cygwin to always sync
the env with windows prior to spawning a child process (any
child process)?

2. How does cygwin work out if it's spawning a cygwin or
non-cygwin binary?  (is it based on refs to cygwin1.dll?)
(is it the loader that does this?)

3. Brian mentioned a call to cygwin_internal(CW_SYNC_WINENV)
In my scenario (see below) I'd have to work out if the target
process was a cygwin proc or not before I tried to invoke this
method ... is there a painless way of working out if a process
is cygwin or not e.g. one that would give me a response whether
the process I'm querying is a cygwin or a native win app?

Why I need the env:
---------------------
	I'm working on a tool which aims to automatically
intercept code builds (e.g. make, nmake etc.) and produce
alternative versions of the compiled code with some enhancements.
The aim is to do this transparently so all a developer need do
is run my spy program, then do a make clean, make and we would
catch all the build commands, grab the command line, working dir
and environment passed to gcc for example and use that info in
the enhanced "compiler" to produce the alternative build.  The
target builds however are not necessarily all cygwin based - e.g.
could be MS builds done via nmake or even an IDE.

Thanks again for your help!

Kaveh.

PS. Eric - I figure that since this is generic cygwin behaviour
there isn't any point in attaching the result of cygcheck now... let
me know if it adds anything and I'll attach it in the next e-mail.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -