This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: Unable to run excel via cron
- From: "Kertz, Denis (D)** CTR **" <d dot kertz at alcatel-lucent dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Wed, 17 Jun 2015 16:29:46 +0000
- Subject: RE: Unable to run excel via cron
- Authentication-results: sourceware.org; auth=none
- References: <883F2CBBC85A62419E181EB2F0ECF21F45DE3905 at US70UWXCHMBA04 dot zam dot alcatel-lucent dot com> <5cd29bc9b87544e98bceea5756738610 at IBTEXCHMB1 dot ibt dot kfa-juelich dot de>
Yes, I was confused, by the system32, but I still managed to do what was suggested. Previously I was running:
c:/Windows/System32/wscript.exe 'c:\cygwin64\home\Upar3\tst.vbs'
Then as suggested I ran:
c:/Windows/SysWow64/wscript.exe 'c:\cygwin64\home\Upar3\tst.vbs'
Both versions of wscript.exe resulted in the same behavior - excel hung.
Denis
------------------------------------------------------------------------------------------------------------
Kiehl, Horst wrote:
Yes, I was confused, by the system32 but I still managed to do what was suggested.
(Trying to remove TOFU to make the conversation appear chronological again and with correct attributions.)
Kertz, Denis (D)** CTR ** <d.kertz at alcatel-lucent dot com> wrote:
> > > We need to run some Excel programs via cron and are using vbscript to do this. We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
> > >
> > > Here's the script to run a simple test excel program:
> > >
> > > [...]
Bryan Berns wrote:
> > What bitness of Excel and Cygwin are you running?
> >
> > CreateObject("Excel.application") will attempt to create a 32-bit
> > instance of Excel when launched through the 32-bit version of
> > wscript.exe or a 64-bit instance of Excel when launched through the
> > 64-bit version of Excel. Which bitness of WScript.exe ends up being
> > run will depend on the bitness of the parent program (which may be
> > different in a command prompt vice Cygwin). Try changing it to run
> > Wscript.exe in SysWow64 instead of System32 (which is subject to
> > automatic redirection) and see if changes the behavior. If you're not
> > running a 64-bit OS, then just ignore everything I said.
Kertz, Denis (D)** CTR ** wrote:
> Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
>
> We are using 64-bit cygwin and 32-bit Excel (Excel 2007).
Although the aspect Corinna wrote about may be the culprit already,
just in case:
It appears that you, Denis, were misunderstanding Bryan. The consequence
of what he tried to point out might be that you, using 64-bit Cygwin and
32-bit Excel, would have to explicitly use the 32-bit wscript.exe
instead of the 64-bit wscript.exe, to make sure that wscript.exe
(32-bit) will start Excel (32-bit) successfully. In other words, you
might have to use $windir/SysWOW64/wscript.exe (i.e.
%windir%\SysWOW64\wscript.exe) from your 64-bit Cygwin process.
(The reason for the seemingly backwards 32-bitness and 64-bitness of
executables in SysWOW64 and system32, respectively, if viewed from a
64-bit process, is to make code with hardcoded "system32", whether
compiled or interpreted, continue to work in a 64-bit context as well as
in a 32-bit context.)
Horst
--
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