This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: expose creating windows-style envblock from current environment
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
implementation.
> 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat, Inc.