> -----Original Message-----
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
> Kiehl, Horst
> Sent: Wednesday, June 17, 2015 8:10 AM
> To: Kertz, Denis (D)** CTR **; cygwin@cygwin.com
> Subject: RE: Unable to run excel via cron
>
> (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
>
Years ago, I had a similar problem on Windows Server 2003. I needed to run a
component of Visual Studio in a
Cygwin-based nightly build system. It would not run unless Visual Studio was
running prior to the builds starting. I
solved it by first bringing up Visual Studio this way.
VISUAL_STUDIO="Microsoft Visual Studio 8"
ps -W | grep -q "$VISUAL_STUDIO" || \
cygstart --showminnoactive \
"/cygdrive/c/Program Files/$VISUAL_STUDIO/Common7/IDE/devenv.exe" /edit
So my question is, does having the Excel UI visible prior to running the cron
job help?
The other difference is I used the Windows Task Scheduler instead of cron to
kick off the nightly build. The .bat file
(still running, but obviously obsolete) is
======
@echo off
C:
chdir C:\cygwin\bin
rem set CYGWIN=ntsec
set CYGWIN=binmode,nodosfilewarning
bash --login -i "/home/build/bin/nightly_bootstrap.sh"
======
This seemed to side-step any problems resulting from the differences in
permission handling between Cygwin and Windows.
--
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
