Thanks, After discussion with Jan Dubois I've added this code as Cygwin::sync_winenv() and revised perlcygwin.pod to use that function when needed. It will be in the upcoming perl-5.14.2-1 package, which is now in test.
The problem to add that generally is that cygwin-1.7 wants now on every occurance of non-posix paths. Initially I thought we should do that unconditionally when loading Win32.pm or Win32::OLE, but we need some tests before. On Wed, Feb 8, 2012 at 11:13 AM, Rafael Kitover <rkito...@cpan.org> wrote: > This is regarding https://rt.cpan.org/Public/Bug/Display.html?id=65052 > > -------- Original Message -------- > Subject: FW: Environment Var Problems with Perl - impact on Win32::OLE > Date: Mon, 6 Feb 2012 15:51:29 +0000 > From: Chris Day <chris_day_serv...@hotmail.co.uk> > To: <rkito...@cpan.org> > > > Yep - not sure you will have seen it. > I seemed to have fixed my own problem (see below) - I am amazed users > have not come across this before. > In my opinion, Cygwin has serve limitations under MS OS from Vista > onwards due to the limited Win32 environment it holds and the use of a > much more diverse one that appears in the newer OS's registry. > Regards, > Chris. > > ---------------------------------------- >> From: chris_day_serv...@hotmail.co.uk >> To: chris_day_serv...@hotmail.co.uk; cyg...@cygwin.com >> Subject: RE: Environment Var Problems with Perl - impact on Win32::OLEþ >> Date: Wed, 25 Jan 2012 17:59:22 +0000 >> >> >> I seem to have found the problem. >> >> It is due to the restricted Win32 environment that exists in Cygwin (see the >> bottom of this page http://cygwin.com/cygwin-ug-net/setup-env.html). >> >> This restricted environment doesn't include the likes of >> %COMMONPROGRAMFILES% that is now used heavily in the registry of newer MS >> OSs (major versions > 5 - ie from Vista onwards). >> >> It would be great if Cygwin provided an option (say in CYGWIN) to load the >> complete current Win32 enviroment at startup - if it does and I have missed >> this I would be very inetrested to know. >> >> As a simple attempt to work around this I have modified my local copy of the >> Win32.xs file in the Perl Win32 module of Jan Dubios to include >> >> #include <sys/cygwin.h> >> XS(w32_SyncCygwinWin32Env){ cygwin_internal (CW_SYNC_WINENV);} >> newXS("Win32::SyncCygwinWin32Env", w32_SyncCygwinWin32Env, file); >> >> >> then at the very start of my Perl file I have >> >> BEGIN { require Win32; Win32::SyncCygwinWin32Env(); } >> >> >> it needs to be at the start and in BEGIN {} so that it runs at complie time >> and before any call to the likes of "use Win32::OLE" which need the full >> Win32 enviroment. >> >> I suspect this is not a very good way of doing this, but if anyone knows a >> better solution then please let me know. >> >> Thanks, >> >> Chris. >> >> >> ---------------------------------------- >> > From: chris_day_serv...@hotmail.co.uk >> > To: cyg...@cygwin.com >> > Subject: Environment Var Problems with Perl - impact on Win32::OLEþ >> > Date: Tue, 24 Jan 2012 11:50:09 +0000 >> > >> > >> > Hi All, >> > >> > In attempting to move some perl (5.10.1-3) code from a Windows XP (Cygwin >> > 1.7.9) environment to a Windows Server 2008 R2 (Cygwin 1.7.9 with perl >> > 5.10.1-3) I seem to have discovered a problem with Cygwin/Perl not >> > resolving most Microsoft environment strings. >> > >> > For example, running the following from a Cygwin bash shell (or seemingly >> > any Cygwin shell) on any of the XP, Windows 7 and Server 2008 2 machines I >> > have: >> > >> > bash$ perl -e "use Win32; print Win32::ExpandEnvironmentStrings('%OS%')" >> > all give >> > %OS% >> > >> > While running this from cmd.exe: >> > >> > C:\cygwin\bin>perl -e "use Win32; print >> > Win32::ExpandEnvironmentStrings('%OS%')" >> > gives the correct answer of >> > Windows_NT >> > >> > This problem seems to exist for all environment variables I have tried, >> > strangely apart from %PATH%. I am not sure if this is a Perl or Cygwin >> > issue. I have tried a newer version of Perl with the same results. >> > >> > This problem resolving environment variables really shows up when using >> > attempting to use certain COM libraries on Windows7 or Windows Server (I >> > guess with Vista also), as in these OS Microsoft has started to use >> > environment variables in the registry paths of lots of their libraries, >> > whilst they did not do this with XP. >> > >> > I think it is for this reason people have been experiencing problems with >> > ADODO and other COM functions using Win32::OLE. >> > >> > For example, the ADODO.Connection registry key on Windows 7 >> > (HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}) >> > has library path as %CommonProgramFiles(x86)%\System\ado\msado15.dll >> > while under XP the ADODO.Connection registry key has its library as >> > C:\Program Files (x86)\Common Files\System\ado\msado15.dll. >> > >> > On my Windows 7 machine, I have tried changing the directory path to from >> > %CommonProgramFiles(x86)% to C:\Program Files (x86)\Common Files in the >> > aforementioned registry key and now Win32::OLE->new('ADODB.Connection') >> > works, albeit opening a DB connection would require a whole host of other >> > similar registry changes (I do not recommend this, I just did it as a >> > test). >> > >> > I am hoping that someone knows how to fix this or knows a workaround? >> > >> > Best regards, >> > >> > Chris. >> > >> > -- >> > Problem reports: http://cygwin.com/problems.html >> > FAQ: http://cygwin.com/faq/ >> > Documentation: http://cygwin.com/docs.html >> > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >> > >> > -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
