> 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 ChangeLog environ.cc environ.h (win_env::add_cache): Add value to environment immediately if "immediate" is set. http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?c vsroot=uberbaum&r1=1.109&r2=1.110 "immediate" defaults to false. I couldn't find a user-configurable way of setting it to true. This is the only place that calls the win32 SetEnvironmentVariable function - as opposed to putenv. For why this is bad for our purposes, over to MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/ _crt__putenv.2c_._wputenv.asp "_putenv and _wputenv affect only the environment that is local to the current process; you cannot use them to modify the command-level environment. That is, these functions operate only on data structures accessible to the run-time library and not on the environment "segment" created for a process by the operating system. When the current process terminates, the environment reverts to the level of the calling process (in most cases, the operating-system level). However, the modified environment can be passed to any new processes created by _spawn, _exec, or system, and these new processes get any new items added by _putenv and _wputenv." OK, so the Oracle DLL is unlikely to see any of these changes when it gets dynamically loaded into the current Perl process - since the real process-level environment block is unchanged via (perl)$ENV -> (cygwin)putenv -> cache and/or (win32)_putenv. Whereas: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas e/setenvironmentvariable.asp "The SetEnvironmentVariable function sets the contents of the specified environment variable for the current process." We want that called when a (Cygwin) environment variable is changed. More supporting evidence that's it's a Cygwin-level issue: http://www.cygwin.com/ml/cygwin/1999-04/msg00473.html There's a "noenvcache" option for the CYGWIN environment variable, but since the only place that SetEnvironmentVariable is called is actually inside the cache code, that doesn't help. It works on the native win32 version of Perl, because in $PERL_SRC/win32/win32.c, function win32_putenv _does_ call SetEnvironmentVariable. So, what's the options? Here's some: (1) Get Cygwin changed to sync up the win32 process environment with its own environment more aggressively - or at least, to have the option to do so (since it was presumably changed to not doing this for a good reason). (2) Get Perl on Cygwin to call the native win32 SetEnvironmentVariable at the same time as the cygwin putenv. This is probably a bad idea, since cygwin does some conversion on environment variables that this would likely interfere with. (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 that looked promising was Env::C - but even though this has "#if defined(WIN32)" tests, that just switches to using _putenv instead of putenv - but not SetEnvironmentVariable. (4) Limit the test suite under cygwin to only run those tests where NLS_NCHAR is already set to the required value - i.e. never actually call set_nls_nchar(). (1) and (2) would obviously take a while and need the agreement of the maintainers of each. I can have a look at (3) in DBD::Oracle, but it'll probably involve some C, since the Win32 module (installable from cygwin's installer as perl-libwin32) doesn't include SetEnvironmentVariable, and Win32::API won't build. Option (4) reduces the nchar test coverage quite a bit, so it's not very satisfactory, but it would be simplest. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
