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.