expose creating windows-style envblock from current environment

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Oct 24 13:46:00 GMT 2005

On Oct 24 03:02, Yitzchak Scott-Thoennes wrote:
> On Mon, Oct 24, 2005 at 11:48:03AM +0200, Corinna Vinschen wrote:
> > On Oct 23 18:08, Yitzchak Scott-Thoennes wrote:
> > > I need to translate the current environment in a cygwin C program to
> > > an envblock suitable for calling CreateProcess directly, and couldn't
> > > think of a better way than the following patch.
> > 
> > I'm wondering why that's necessary at all.  You have access to the app's
> > POSIX environment and you know by a simple look into Cygwin which
> > variables have to be path converted and which not.  That can be done
> > using cygwin_conv_to_win32_path/cygwin_posix_to_win32_path_list.  Looks
> > like a task easily accomplished inside of the application.
> I seem to recall changes over time in which variables get converted
> (or forced to exist) it would be nice, though not mandatory, to
> automatically stay in synch.  Unless you are outright rejecting

Hmm, it *is* pretty stable.  AFAIR there was only a SYSTEMROOT problem
once and a LD_LIBRARY_PATH which was accidentally converted.  Given that
latter example, you might even be better off with an application side

> having a way to do this, I'll play with it some more.  Perhaps
> a new function would be better, but I don't know how to get a new
> function exported by the dll.

Definitely not.  *Iff* we add such a functionality, it should really be
using the cygwin_internal interface.  But still, I'm not sure that's the
way to go.

> > > As an aside, does the build_env call in spawn.cc leak?
> > 
> > How?
> By never freeing moreinfo->envp in the parent?  I couldn't follow how
> moreinfo/ciresrv are being used, other than that they get passed somehow
> to the child.

Hmm, I must admit that I don't see freeing moreinfo in the parent myself,
so Chris might shed some light.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

More information about the Cygwin-patches mailing list