X-Spam-Check-By: sourceware.org Message-ID: <44543FE2.5070208@arkasoft.com> Date: Sun, 30 Apr 2006 05:41:06 +0100 From: Kaveh Goudarzi 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: List-Archive: List-Post: List-Help: , 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/