On Tue, Jan 17, 2006 at 08:04:42PM -, Andy Hassall wrote:
> > > (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly
> >
> > I'd be willing to add a cygwin-specific function to DBD::Oracle
> > (Oracle.xs and dbdimp.c) that calls SetEnvironmentVariable().
> >
> > Patches welco
> > (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly
>
> I'd be willing to add a cygwin-specific function to DBD::Oracle
> (Oracle.xs and dbdimp.c) that calls SetEnvironmentVariable().
>
> Patches welcome :) [An estimate of the time required would help since
> I'm readying a
On Mon, Jan 16, 2006 at 11:58:48PM -, Andy Hassall wrote:
> So, what's the options? Here's some:
I haven't looked at the code that's failing, so some of my comments may
be misguided.
> (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly, at
> least during the testsuite, if
On Mon, Jan 16, 2006 at 11:58:48PM -, Andy Hassall wrote:
>
> So, what's the options? Here's some:
> (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly, at
> least during the testsuite, if building on Cygwin, rather than (or in
> addition to) writing to $ENV. One module th
> It sounds like the behavior is what you'd expect if %ENV was cached
> instead of live (ie manipulating %ENV didn't alter the processes own
> 'native' environment variables until a subprocess was spawned).
Bingo.
http://www.mail-archive.com/cygwin-cvs@cygwin.com/msg02867.html
"
winsup/cygwin